steps to reproduce: 1) dd if=/dev/zero of=large_file seek=4G bs=1 count=2 2) launch mozilla 3) load the directory that contains that file actual results: Mozilla shows _some_ of the files in that directory. expected results: mozilla shows all of the files, the large file with incorrect file size reason why this is failing: nsLocalFileUnix uses stat(). that fails when the file is larger than 4 GB. there's this nice XXX comment: /* XXX autoconf for and use stat64 if available */ on line 1066. I suspect the NSPR functions could easily be used and they do have such an autoconf test. see: http://www.mozilla.org/projects/nspr/reference/html/priofnc.html#17758

:( PR_GetFileInfo64 doesn't work, for two reasons: it doesn't give access to permissions, and it gives an error if the file is a broken symlink (the current code seems to handle it and call lstat)

Comment on attachment 145876 [details] [diff] [review] how about this i'm not very keen on #define'ing like this. i'd rather see us write inline helper functions to abstract the stat64 vs. stat business, but this will do. r+sr=darin

Checking in configure.in; /cvsroot/mozilla/configure.in,v <-- configure.in new revision: 1.1338; previous revision: 1.1337 done Checking in xpcom/io/nsLocalFileUnix.cpp; /cvsroot/mozilla/xpcom/io/nsLocalFileUnix.cpp,v <-- nsLocalFileUnix.cpp new revision: 1.114; previous revision: 1.113 done Checking in xpcom/io/nsLocalFileUnix.h; /cvsroot/mozilla/xpcom/io/nsLocalFileUnix.h,v <-- nsLocalFileUnix.h new revision: 1.21; previous revision: 1.20 done

Comment on attachment 145876 [details] [diff] [review] how about this would be nice to get this to the branch; this fixes directory listings (which, without this patch, only show a few files if the directory contains a large file)

Comment on attachment 145876 [details] [diff] [review] how about this nevermind the approval requests. well, tinderboxes didn't like this change - "mCachedStat has incomplete type". I backed out the patch.

(although I left the configure.in changes in, as they might be useful for a new version of the patch) however, I don't really want to work on that anytime soon, so -> default owner

The problem is that the decl of that member is: 95 struct stat mCachedStat; and you #defined'd "stat" to something else. The right solution is probably to use STAT() instead of stat() throughout and define that....

bz: I did that intentionally - I want a "struct stat64" here, because I want the 64-bit filesize member. see for example http://www.mcsr.olemiss.edu/cgi-bin/man-cgi?stat64+2

Oh, hrm... so autoconf found a stat64 function but the stat64 type was not defined? Suck. :(

hm, this did not break luna, which is running redhat 8... maybe an autoconf check should be added for "struct stat64"...

is this bug meant for file:// URLs or for the file-dialog? I've observed with Firefox 1.0.3 that I can't change into a (local) directory with file:// if the directory contains files larger than 2GB. It stays in the former directory.

could be that that's also caused by this bug, yes.

I think this bug was fixed as part of bug 278738.

Looks like it, yes.