On 19 Jul 2013, at 20:19, roger riggs <roger.ri...@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 >
