Firefox cannot launch on large filesystems




6 years ago
4 years ago


(Reporter: Griff Miller, Unassigned, NeedInfo)


8 Branch

Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

Firefox 8 installed in my home directory. IT people subsequently moved my home directory to a different (huge) filesystem on Isilon server.

Actual results:

After move to huge filesystem, firefox would not launch, saying "Couldn't calculate the application directory". Moved firefox install to local workstation disk, which got me past that error, but then I got "Could not stat private per-user gnome configuration directory" .

Same problem with fresh install of firefox.

With the 2nd error, using strace, I could see that the stat64() call on the directory mentioned had succeeded, but firefox was erroring out because it apparently thought the inode # was too large.

I created the .gnome2_private directory on a local fs, and made a symbolic link to it from my homedir, and then firefox would launch (using the firefox installed also on the local fs).

Expected results:

Firefox should have launched. I don't see why it feels it necessary to police what it gets back in the statbuf if the stat call succeeded.
Can you specify the "large" in "large filesystem" ?
The error message comes from here :
And the code that failed, to reach that error message:
The "Could not stat private per-user gnome configuration directory" error message comes from libgnome, so firefox is not responsible for that one.

Comment 4

6 years ago
% df -k .
Filesystem           1K-blocks      Used Available Use% Mounted on
                     69638271744 43249721920 26388549824  63% /users/gmiller

The inode on a newly-made directory is 4380593270 (firefox does a mkdir of ~/.gnome2_private if it does not exist).

So we'll forget about the 2nd error message with ~/.gnome2_private .  I will attach an strace log for the first message.

BTW, I get the same first message with Thunderbird.

File attachment to follow.

Comment 5

6 years ago
Created attachment 579389 [details]
strace -v when firefox installed on large NFS filesystem (with big inodes)

Comment 6

6 years ago
Let me update you with some more information.

First of all, I must apologize on getting a crucial detail wrong (although it has a similar effect): my home directory (and thus my firefox and thunderbird installs) was not moved to the isilon server; it was already there, but the isilon server software was upgraded. Part of this upgrade (according to my IT people) involved "isilon changed from 32 fileid to 64 fileid in the upgrade" .  I am guessing that by "fileid" they mean inode number.

They have since switched the isilon back to 32-bit "fileid's" and firefox and thunderbird work again.

Incidentally, xxdiff (if you are familiar with that program) also had a problem with the 64-bit "fileid's".

So, it sounds like (as I suspected from the beginning) that something doesn't properly handle "big" inodes. Whether that is in firefox/thunderbird, or in a library somewhere, you will be able to say more readily than I.

Perhaps the problem is that my OS (RHEL5) is too old to understand 64-bit inodes.
How exactly do you launch firefox? Do you give a full path? Just "firefox"? What is your PATH?

Comment 8

6 years ago
I have a button I set up on my KDE3 panel that invokes /users/gmiller/firefox/firefox .  That's the same thing I do if I need to launch it from the command line, like for all this troubleshooting. The path is:


I meant to mention in my last update that I haven't come across a system command (e.g. ls) that had trouble with the big inodes - just thunderbird, firefox, and xxdiff .

Comment 9

4 years ago
Does this issue still reproduce with current Firefox builds?
Flags: needinfo?(griff.miller)

Comment 10

4 years ago
Please only reopen this bug if you can reproduce it on current builds.
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.