User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041130 Mnenhy/0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a6) Gecko/20041130 Mnenhy/0.7 If a directory /foo/bar/ contains a file with size larger or equal to 2GB the file:///foo/bar/ will not be reached when clicking on "bar" in the listing of file:///foo/. Reproducible: Always Steps to Reproduce: 1.Create a directory /foo/bar/. (Both directories /foo/ and /foo/bar/ world-readable to be on the safer side.) 2.Create a file /foo/bar/largefile with size >= 2GB 3.Open in mozilla file:///foo (-> the page "Index of file:///foo" is shown) 4.Click on the link "bar" (leading to file:///foo/bar/) Actual Results: *Nothing* happens. Expected Results: The listing "Index of file:///foo/bar/" should be shown. I can reproduce this problem with (CVS-)mozilla-suite from both today and 2004-05-29, so it's not a nightly problem. This seems to be a Linux-only problem, resp. not a Windows problem. Windows browsers (both FF and SM) did not have this problem. See the corresponding (german) thread <npnsb2-h5i.ln1@faith.die-moells.de> ff in de.comm.software.mozilla.browser. On Linux I created the large_file with: "dd if=/dev/zero of=large_file bs=1048576 count=2048". (If large_file is created with count=2047 the problem does not appear.) And before someone asks: This is *not* a problem of the filesystem: I can create files with size much more than 2GB.

bug 240192 would fix this

ACK that with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050111 Firefox/1.0 (NESI) Mozilla/5.0 (X11; Linux i686; U;) Gecko/0 Kazehakase/0.2.3 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050111 Galeon/1.3.19 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050111 Epiphany/1.4.7 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050111

well, yeah. that's no surprise at all. the code does a stat (not a stat64), and that fails for files > 2 GB. the code then stops processing the directory index when it sees the error.

-> necko, maybe the directoryindexstream's behaviour can be improved

*** Bug 298594 has been marked as a duplicate of this bug. ***

*** Bug 303262 has been marked as a duplicate of this bug. ***

I verified that this bug can be worked around compiling the mozilla suite with the additional compiler options -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. If anyone is interested I can construct a clean patch to autoconf generating the correct compiler options.

This is a patch relative to mozilla-1.7.11 (Patch relativ to trunk follows). It enables Large File Support (LFS) for the platforms I know. IRIX and FreeBSD is LFS per default. I do not know how to enable on OS X/Darwin. Since we use autoconf 2.13 one cannot use the macro AC_SYS_LARGEFILE.

Relative to mozilla-1.7.11, relative to trunk follows. Even a 64 Bit mozilla does not display the size of Files > 2GB correctly. Removing a bogus cast down to 32 bit.

Sorry typo

Same for trunk. Sorry, I get errors trying to recreate configure... Is there a specific instruction to rebuild configure on trunk?

One last note: I am going on vacation now until 9/12. Will answer email afterwards.

(In reply to comment #11) > Is there a > specific instruction to rebuild configure on trunk? "run autoconf2.13" I'm not sure this is best, though... why not use the patch from bug 240192 and add just the preprocessor macro that it was missing (I don't know which one that is)? Using NSPR here would be even better but doesn't give all the information nsLocalFileUnix wants :(

(In reply to comment #15) > *** Bug 368487 has been marked as a duplicate of this bug. *** > No this is not a duplicate: It supplies compiler with the correct compiler flags -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 in order for my patch to work correctly. I supplied these Flags "by hand".

I think the patches have the same goal, to pass the correct flags to the compiler. The patch for Bug 368487 is one possible way to fix the problem for Solaris, not the others. It's better that we can make all the platforms working.

dougt, ben, any suggestions from you on this bug? To add -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 to the compiler flag can be a possible solution for this bug.

I think it would be safer for all platforms if we just use stat64() when available. This patch just does this (note the test for stat64 and lstat64 is done in configure.in already, so there was no need to add it) (not tested, though)

This should work better

This one builds, at least.

This is getting embarassing. This one builds.

Now, without the spurious changes to config.* files. I validated this solves the issue on x86.

Please consider using stat() and the large file support LFS. My old patch implemented this. Using stat() is a much more clean API. stat64() is only a way to get 64 bit file infos for ancient 32 Bit codes. Please consider using LSF. Do not use stat64(), since it is not portable. Introduction to LSF for instance at: http://www.suse.de/~aj/linux_lfs.html (Using LSF) Olaf

(In reply to comment #25) > Please consider using stat() and the large file support LFS. > > My old patch implemented this. Using stat() is a much more clean API. stat64() > is only a way to get 64 bit file infos for ancient 32 Bit codes. > > Please consider using LSF. Do not use stat64(), since it is not portable. > > Introduction to LSF for instance at: > http://www.suse.de/~aj/linux_lfs.html (Using LSF) The thing is: linux is not the only platform supported by this code, and it's probably safer to use stat64 when supported than to use large file support for stat(). Also, forcing LFS might break other things where stat is used directly and st_size is assigned to a 32 bit variable.

We build mozilla in the past for AIX, HPUX and Solaris with my patch, supporting LSF and the 2GB limit was away. Our customer used mozilla built this way for years. (stat64 isn't WIN32 neither ;-) Please clean the few missing bits (have a look at my patch) and the problem is away, forever. stat64() does not work as expected on 64Bit UNIX platforms -- it is simply not there. If I remember correctly: HPUX 64Bit API (or was it AIX?) You can leave out all the #ifdef, your code is clean and actually works! Please think twice before committing more #ifdef code. I cannot believe that this simple patch is not going into release _for years_. Even perl is LFS clean for years. Olaf

> (stat64 isn't WIN32 neither ;-) Win32 doesn't use this code > Please clean the few missing bits (have a look at my patch) and the problem is > away, forever. I'm amazed the compiler doesn't choke on the size = symStat.st_size in the same file, when size is a PRInt32... it's fortunate that this code is symlink specific and that it's unlikely there are 2GB+ symlinks out there. Let's just hope some other code doesn't do similar things elsewhere... Also, this file is put in a static library that is embedded in a lot of different stuff, and while I know there is no problem on glibc based systems because basically stat with LFS enabled ends up being stat64, I'm not sure linking something else using non LFS stat with this .a using LFS stat would not end up with subtle breakages.

Yep, you should try to change the configure process. This is what we had done in the past to enable LFS for the complete mozilla suite. https://bugzilla.mozilla.org/attachment.cgi?id=193166 Linking non-LFS and LFS code will surely give a desaster area.

Landed before branching

I believe that: https://bugzilla.mozilla.org/show_bug.cgi?id=474291 and https://bugzilla.mozilla.org/show_bug.cgi?id=389087 are duplicates of this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=232371 is for SeaMonkey, but looks the same. https://bugzilla.mozilla.org/show_bug.cgi?id=446163 is possibly related and may have been resolved as part of this bug.