232371 - Filesizes are truncated to 32 bit

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Christian Biere]

User-Agent:       
Build Identifier: 

If you browse a local directory which contains a huge file (several Gigs)
Mozilla will either refuse to show the directory at all (Solaris 2.8 and Mozilla
compiled without LFS) or show wrong filesizes. I think the source of
this problem is here:

    http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#234

Note that size_t and off_t are casted to a 32-bit wide integer type. There might
be similar bugs elsewhere.
I suggest to audit the code WRT to off_t, ssize_t, size_t and also time_t(!).

Reproducible: Always
Steps to Reproduce:
1. dd if=/dev/zero of=/tmp/huge_file bs=1m count=8k
2. mozilla file:///tmp/
3. Note what filesize Mozilla reports or wonder why Mozilla doesn't show the
directory at all.

Actual Results:  
Solaris, Mozilla w/o LFS:
No error, no warning no nothing. A trace log shows that fstat() fails with
EOVERFLOW.

Solaris, Mozilla w/ LFS or Tru64 UNIX:
The directory listing shows an incredible small file 'huge_file'. Probably only
the lower 32 bits.


Expected Results:  
Guess what.

Comment 1

[Christian Biere]

Oops, wrong line. Here are some examples:

http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#1064
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#1078
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#1093
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#1408

Comment 2

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

that's one problem but there are others... e.g.
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsDirectoryIndexStream.cpp#353

similar to bug 184452... this one is more specific though

Comment 3

[nemo]

Yes, it does seem odd that the other bug is focused on >32bit downloads, while
ignoring what happens to such files once they are actually on your disk.
Wonder if there is a generic 64bit tracking bug somewhere.  You'd think somone
would've thought of it by now.

Comment 4

[Jeff Walden [:Waldo]]

Re comment 3: see the 64bit keyword.  It's not specifically designed for this
situation, but with it it's easy enough to see what's wrong with a 64-bit
Mozilla (Firebird).

Comment 5

[nemo]

Yes, 64bit conversion bugs were all I could find.  And you're right.  It isn't
quite the same thing, although similar problems will be encountered.
This applies to 32bit OSes as well.
Oh well, seems unique in its own right, well described and easily confirmed.

Comment 6

[Prognathous]

Is this the bug that recently killed ben's and bsmedberg's mailboxes?

http://weblogs.mozillazine.org/ben/archives/006993.html
http://www.saintpatrickdc.org/bsmedberg/index.php?p=35

Prog.

Comment 7

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

prognathous: no. I suspect that was bug 207400 (which is fixed on trunk)

Comment 8

[Robert]

I can confirm this bug on Linux and Firefox 2.0.0.6 (actually Debian's Iceweasel).

Comment 9

[Robert]

Sorry. The exact behavior of my system is that the browser refuses to list the directory containing the big file at all.

Comment 10

[mammique]

Same for me under Ubuntu with both FF2 and FF3. Too bad i spent weeks to hack and learn XPCOM to build a large file uploader extention... Have to give up for another archaic but working technologie :-/

Reproducible with this code, a file bigger or smaller than 1024*1024*2 bytes:

var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);
file.initWithPath('/path/to/the/file');
alert(file.fileSize);

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalFile.fileSize]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://....file.js :: file_test :: line 39"  data: no]
Source File: script.js
Line: 39

Comment 11

[David Bradley]

Anyone still seeing this problem. Bug 184452 seems to have been addressed, so guessing this one is now ok as well.

Comment 12

[David Bradley]

I looked at the code in question and fileSize and other areas are using 64 bit integers now. So going to mark this fixed. If anyone is still seeing issues, please reopen.