User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Build ID: 20130307023931 Steps to reproduce: Running FF on OSX Lion or later with profiles stored on NFS share results in intermittent lose of newly added bookmarks. Actual results: Environment: * Multiple Mac OSX Lion and Mountain Lion clients with home directories on NFS shares on a NetBSD server. * FF profile stored in default location: ~/Library/Application Support/Firefox... * Multiple users on each client. * Firefox versions 18 and 19. Although this issue has been seen prior to 18 also. Reproducing: * All testing done by cleanly shutting Firefox, no crashes or network issues. * In normal production the problem can be intermittent however using the following procedure makes the issue consistently reproducible. * Can reproduce using a new or existing profile 1. Preparation: * Start Firefox * Load up > 6 tabs to random sites * Bookmark the group of tabs * Close Firefox 2. Reproduction * Start Firefox * Open all tabs in bookmarked group * After activity is settled, open 1 or more new pages and add 1 or more bookmarks * Close Firefox * Start Firefox * Newly added bookmarks are missing but original ones are still present. 3. Observations * Firefox is not using WAL with sqlite on the NFS shares. Instead "-journal" files are used. * A places.sqlite-journal is observed in the profile: * Usually created as soon as some browsing is performed (history changes) * Sometimes left on shutdown * Sometimes removed on shutdown but places.sqlite not updated * Sometimes removed on shutdown and places.sqlite is updated (bookmarks stick around in this case) * places.sqlite is not updated with new bookmarks (based on file time stamp) * places.sqlite has both read and write locks on it when examined on the NFS server. * Opening single pages or not loading down Firefox reduces the chances of reproducing the issue but at times it can also happen consistently even with single tabs loaded. * journal created, places gets updated, journal removed most times * This looks like Firefox is not getting an exclusive write lock on the places.sqlite file but no other applications are operating on the file. Expected results: Testing this on Mandriva Linux 2011.0 using the same NSF mounts results in Firefox using WAL and no issues. Previous to Firefox using WAL (prior to June, 2011) empty places.sqlite-journal files are present in some user profiles but I can't say if this bug existed then or not. Notes: * Turning off NFS locking is not an option in this environment. * If there was a switch to force Firefox to use WAL instead of -journal files, that might be a work-around * If there was a way to force Firefox not to use sqlite, that might be a work-around I have found many other references to Firefox and NFS locking issues and have examined them to see if this is a similar situation. However I have not found this particular issue using the same environment or method of reproduction. I'll gladly post any other debugging information that would help resolve this as right now our Mac users can not properly use Firefox.

Thanks, Merlin -- it sounds like this might be an issue for the History/Bookmarks team to look at.

there are multiple known issues with nfs hosted profiles and SQLite, as a workaround you can go to about:config and set storage.nfs_filesystem to true