Closed Bug 570683 Opened 14 years ago Closed 13 years ago

bookmarks seems to be in use by other application if on NFS-Directory

Categories

(Firefox :: Bookmarks & History, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 436737

People

(Reporter: Der_Sprengmeister, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

I want to use my profile (especially the bookmarks) from my server. For the my profile-directory points to the real profile-directory on my server with NFS.

If I do so, firefox tells "The bookmarks and history system will not be functional because one of Firefox's files is in use by another application."

Reproducible: Always

Steps to Reproduce:
1. symlink the profile-directory on a NFS-device
2. (at least symlink the places-sqlite on a NFS-device)
3. start firefox

Actual Results:  
The bookmarks and history system will not be functional because one of Firefox's files is in use by another application.

But that's not right. The file isn't open by anothher application, the user+permissions are right, it is editable....

Expected Results:  
It should work also over NFS.
I suspect I'm having the same problems moving from Firefox 4.0b8 to 4.0b9 on Solaris 11 Express snv_151a (X86).  All sections above except build and OS identical.

My work machine running Solaris 11 Express has been working fine with an NFS mounted ~/.mozilla (NFSv4 from a Solaris 10 machine).  Upgrading to b9 renders it completely unusable.  No history, and no bookmarks.  It comes up with the "The bookmarks and history system will not be functional because one of Firefox's files is in use by another application.  Some security software can cause this problem." bar, and renames my places.sqlite to .corrupt, and after completely deleting the firefox directory and letting b9 create a new one from scratch.

My home machine, running OpenIndiana 148 and with local $HOME but apart from that pretty similar, goes through the same upgrade with no problem.  I suspect looking through the bug reports here that the key difference is the NFS vs. local home filesystem.  It appears something has changed between 4.0b8 and 4.0b9 to make SQLite much more fragile in the face of network filesystems.

I think this bug deserves much higher priority, because it must be very common for people to have their home directories on a network filesystem.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.