Re: [jgit-dev] nio exception

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Thu, Mar 8, 2012 at 22:57, Markus Duft <markus.duft@xxxxxxxxxx> wrote:
> On 03/07/2012 04:30 PM, Shawn Pearce wrote:
>> On Tue, Mar 6, 2012 at 23:17, Markus Duft <markus.duft@xxxxxxxxxx> wrote:
>>> On 03/07/2012 03:32 AM, Shawn Pearce wrote:
>>>> On Tue, Mar 6, 2012 at 05:16, Markus Duft <markus.duft@xxxxxxxxxx> wrote:
>>> [snip]
> [snip]
>>> problematic here is the in.getChannel().size()... this uses a NIO channel to determine the size of the file (lol). This is the step that can fail. I'm not really sure what would be the best solution here, but i think a simple "final long sz = path.length();" would do instead. or is File.length() somehow bad? or more bad than Channel.size()?
>>
>> Whoops. The problem with path.length() is the inode could have changed
>> out from under us between when the file was opened, and when the size
>> was estimated. The only safe way to know is to use the channel to get
>> at fstat() in the system, or to use the path.length() as an estimate
>> for the buffer size but be prepared to grow or shrink our buffer if
>> the actual file length is larger or smaller, as determined by when
>> read() returns the EOF indicator.  :-)
>
> are you really sure this is a problem? i checked the openjdk implementation of FileSystem.getLength() (which is used by File.length()), and it does a stat() on the path always. this should be for sure sufficient to not confuse anything :) it will also catch the case where inodes change. nothing is cached. nowhere. if there are java implementations that do cache - i think, _thats_ the bug then ;p

Yes, it is a problem:

  Thread 1:

    FileInputStream in = new FileInputStream(....);

  Thread 2:

    echo hi >config.new; mv config.new config

  Thread 1:
      long len = path.length();  // now 3 instead of say 4000.