Re: [jgit-dev] nio exception

[Markus Duft <markus.duft@xxxxxxxxxx>]

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

Java_java_io_UnixFileSystem_getLength:
	struct stat sb; 
	if (stat(path, &sb) == 0) {
		rv = sb.st_size;
	}

Java_java_io_Win32FileSystem_getLength:
	struct _stati64 sb; 
	if (_stati64(path, &sb) == 0) {
		rv = sb.st_size;
	}

Java_java_io_WinNTFileSystem_getLength:
	if (GetFileAttributesExW(pathbuf, GetFileExInfoStandard, &wfad)) {
		rv = wfad.nFileSizeHigh * ((jlong)MAXDWORD + 1) + wfad.nFileSizeLow;
	} else {
		...
		struct _stati64 sb; 
		if (_wstati64(pathbuf, &sb) == 0) {
			rv = sb.st_size;
		}
	}


Regards,
Markus