RFR  java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0
roger.riggs at oracle.com
Fri Jul 19 19:19:14 UTC 2013
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
>>> 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