240192 - nsLocalFileUnix breaks for files larger than 4 GB

Status: RESOLVED DUPLICATE of bug 278738

(Core :: XPCOM, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

:( 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 2

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: how about this

Comment 3

[Darin Fisher]

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

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

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 5

[Christian :Biesinger (don't email me, ping me on IRC)]

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 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

Comment 8

[Boris Zbarsky [:bzbarsky]]

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....

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 12

[Wolfgang Rosenauer [:wolfiR]]

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.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 14

[jag (Peter Annema)]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

Looks like it, yes.