

A one line user.js file specifying the desired bookmarks file copied to each profile did the trick, and worked flawlessly. I simply wanted all browsers to *use* the same file. Or we recognized the possibility of race conditions, and *didn't* open the same bookmarks file from more than one browser at a time. > used this either got used to minimal changes or the dataloss scenarios.) > by overwriting the bookmarks) are not being recognized (I guess people who > condition bugs in the old implementation (whichever browser closed last "won" We have never considered this a supported behaviour, and the race > This is not a features I believe we will bring back as it was implemented in An enhancement request covering that should be filed if people really want it, but this is not how we'd solve such a request, in any case. I understand that this doesn't solve certain use-cases, but issues like "we want a hardcoded bookmarks set" are not currently a priority for a consumer-oriented product such as Firefox. Spending time on a hack with serious drawbacks is not something we have time or resources for, so I'm going to mark this as WONTFIX. You can already use Weave, and you can even put it on your own webdav space (its encrypted and decrypted on the client, so you don't have to worry about storing it in plain sight). What we are working on with Weave will replace this behaviour with a secure and resilient solution for keeping data synchronized across multiple machines and OSes. We have never considered this a supported behaviour, and the race condition bugs in the old implementation (whichever browser closed last "won" by overwriting the bookmarks) are not being recognized (I guess people who used this either got used to minimal changes or the dataloss scenarios.) This is not a features I believe we will bring back as it was implemented in Firefox 2. I *could* create a hard link between the desired common file and the target directories where my profiles live. NTFS supports hard links and symbolic links, though the functionality is not exposed to the user, and I have tools to create links. Yes, there's a work-around outside of FF: I rung FF on WinXP with NTFS 5. Sure, if more than one browser was active at a time, corruption could occur, but I'm aware of that and don't have multiple Mozilla based browsers active in practice.īeing able to have all Mozilla browsers share a common bookmarks file is an extremely important feature to me, and this may just keep me from migrating to FF 3. Under FF 2, a simple one line user.js file copies into every profile, and pointing at the desired common file did the trick. For the most part, I want them all to use the same bookmarks file, to avoid the synchronization problems when all browsers have local copies and there's no convenient way to propagate changes made in one to the others.

I also have other Mozilla based browsers in the mix, including SeaMonkey, Netscape, and Flock. I have multiple profiles, customized for different purposes. Count me as someone who considers this a serious regression.
