RFR  java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0
chris.hegarty at oracle.com
Fri Jul 19 19:52:08 UTC 2013
On 19 Jul 2013, at 20:19, roger riggs <roger.riggs at oracle.com> wrote:
> Hi Ivan,
> You may need someone with more NIO experience to weigh in on this.
> Since the initial size can't be trusted (at least for zero), the code could
> replace the zero with a modest buffer size (8192) and continue as is.
> The code already checks if the bytes read is the same as allocated
> and returns a copy with the exact bytes as needed.
> To be fully robust, the loop should be updated to reallocate the buffer
> array if it is too small.
> On 7/19/2013 2:11 PM, Ivan Gerasimov wrote:
>> On 19.07.2013 21:43, Remi Forax wrote:
>>> On 07/19/2013 07:15 PM, Ivan Gerasimov wrote:
>>>> Hello everybody!
>>>> Would you please review a fix for the problem with j.n.f.Files.readAllBytes() function?
>>>> The current implementation relies on FileChannel.size() to preallocate a buffer for the whole file's content.
>>>> However, some special filesystems can report a wrong size.
>>>> An example is procfs under Linux, which reports many files under /proc to be zero sized.
>>>> Thus it is proposed not to rely on the size() and instead continuously read until EOF.
>>>> The downside is reallocation and copying file content between buffers.
>>>> But taking into account that the doc says: "It is not intended for reading in large files." it should not be a big problem.
>>>> The fix is for JDK8. If it is approved, it can be applied to JDK7 as well.
>>>> Sincerely yours,
>>>> Ivan Gerasimov
>>> Is not better to just not trust the filesystem when a call to size() returns 0 ?
>> Then we couldn't use Files.readAllBytes() to read /proc/* files.
>> Here's what the documentation says about Files.size(): "The size may differ from the actual size on the file system due to compression, support for sparse files, or other reasons."
>> So it is already said, that the exact file size is not always known.
>> Then why should we rely on this information when trying to read all bytes of the file?
>> Sincerely yours,
More information about the core-libs-dev