RFR [8020669] java.nio.file.Files.readAllBytes() does not read any data when Files.size() is 0

[Chris Hegarty]

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.

+1

-Chris.


> Roger
> 
> 
> 
> 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.
>>>> 
>>>> http://bugs.sun.com/view_bug.do?bug_id=8020669
>>>> http://cr.openjdk.java.net/~igerasim/8020669/0/webrev/
>>>> 
>>>> 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,
>> Ivan
>> 
>>> Rémi
>