Closed Bug 385077 Opened 17 years ago Closed 16 years ago

ability to set path to places.sqlite by a preference like browser.bookmarks.file did

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: aryx, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [Fx2-parity]) 

Until Firefox 2.0.0.*, the user could specify the path of the bookmarks file by creating the preference browser.bookmarks.file and the path as value. This allowed the creation of multiple profiles with different settings and extensions for special tasks and allowed to access the bookmarks from every profile.

Dietrich told that this is not planned for Firefox 3, so I am filing this bug. I chose regression and not enhancement because the functionality was lost. Allowing the people to easily access bookmarks and in test profiles etc. is a vital aspect for deep testing like leak tests.

If it does not get restored, how should it be managed during migration to Firefox 3?
Being able to specify the path of the bookmarks file is also very important when using different OS. We have a network with W2k, XP and Linux terminals, and it's important for us that users always have the same bookmarks, independently of the computer they use. 
So, losing this functionality is definitely an important regression for us.
IMHO the lack of this would be a show stopper.
Nominating to get a final decision on this.
Flags: blocking-firefox3?
Whiteboard: [Fx2-parity]
Not blocking on this, as we're hoping to have better ways of doing this using the bookmark sync API.

Also, two users opening the same sqlite file will corrupt the DB.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [Fx2-parity] → [Fx2-parity][wanted-firefox3]
I'd like to have the option to move the database file elsewhere, as I did in 2.*.
One reason is that I can take it to a vfat drive and access it both from my Windows and Linux installations.
I work in support and use several PCs. One of the advantages of Firefox over IE is that it easier to locate the Bookmarks file on a network drive so I can access it from different PCs and very importantly it is backed up every night.
Flags: wanted-firefox3+
Whiteboard: [Fx2-parity][wanted-firefox3] → [Fx2-parity]
I work at a school and the computers here have Deep Freeze on them.  I would like to move the bookmark to a network location as in Firefox 2 so bookmarks can be saved and accessed from any computer in the school.
I understand the appealing of creating a bookmark sync API. But if it somehow can't be done before the RCs or final release, I suggest creating a about:config parameter (something like "whatever.place.file_unsafe") that simulates what we can do in FF2.

I suppose people who use this feature know what they're doing. Many of us really just use this feature to share between OS's on the same computer and not on the network, which means that there will only be one user using the file. Creating such parameter will at least temporarily solve the problem for some of us.
Is there any possibility of allowing the bookmarks.postplaces.html file to be shared among various Profiles on a local machine? Or to allow that file to be moved to a "central location" (out of the Profile folder)?

It's been mentioned here that multiple sqlite users would corrupt the DB, but here it says sqlite implements atomic commit: http://www.sqlite.org/atomiccommit.html.
Is there no way this could be used over a network?
With all due respect to the developers who have spent two release cycles on Places, I do not see any additional utility in places over traditional bookmarks. And, as Beltzner pointed out, this database-mediated system is much more fragile than the already fragile html-based system it replaces. The existence of a backup system only covers for fragility; it does not make the system robust (interestingly, the IE-style file-based bookmarks system is the only robust approach to this function that I have yet seen).

At the risk of some complication, the places database could be locked so that only one user had write access to it at a time. This would prevent db corruption and still allow an out-of-profile location along with bookmark-sharing.

Alternately, fx3 could be built to allow users the option of opting out of the Places db system entirely. This would allow users to correct for a fundamental error in direction by the developers.
Blocks: 317881
(In reply to comment #10)
> bookmarks. And, as Beltzner pointed out, this database-mediated system is much
> more fragile than the already fragile html-based system it replaces. The

Uhm, lies. I never said this. I, in fact, have said the opposite: the transactional based database that we use is *more* reliable than the fragile HTML based system that it replaces.

The scenario I point out above, with the opportunity for DB corruption, is a non-supported user scenario. That doesn't mean that the system's more fragile.
i think the sqlite approach makes for better performance and is a good foundation to expand with tons of features

if simultaneous access is too much to ask, it could be locked by the first browser session acessing it

just getting it to an independant location would already be a breeze

So - what is going to happen then?

If Firefox goes down this route, then it will become unusable in many places.  What about those sites that use Windows and have set (read-only) profiles?  It is common place in many schools.

I just found out about this today. Granted that I usually do not like changes, I am still flexible enough to accept and adjust to the changes that seem meaningful.

However, I don't see this change as one of them. As a database engineer I understand the importance of preventing data corruption, but as others have pointed out, sqlite provides enough atomicity to allow concurrent access to data without causing corruption. IMO, the less control the user has, the worse.

As in comment #1 I use Firefox cross-platform, and share bookmarks through a special path between platforms.
It's truly a show stopper for someone like me, but shouldn't be too difficult for someone with time on their hands to fix.
I'd *really* like to see this fixed....
And if it isn't, will probably have to use some precious time to write a quick hack for this. (I don't have time on my hands)

I can't comment on the network use-case for this bug.
Sounds like this is mode difficult.
Count me as someone who considers this a serious regression.

I have multiple profiles, customized for different purposes.  I also have other Mozilla based browsers in the mix, including SeaMonkey, Netscape, and Flock.  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.

Under FF 2, a simple one line user.js file copies into every profile, and pointing at the desired common file did the trick.  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. 

Being 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.

Yes, there's a work-around outside of FF: I rung FF on WinXP with NTFS 5.  NTFS supports hard links and symbolic links, though the functionality is not exposed to the user, and I have tools to create links.  I *could* create a hard link between the desired common file and the target directories where my profiles live.  But I shouldn't have to.  This should be doable from within FF.

Maybe Weave could be the alternative ?
Please... allow us to specify the path to places.sqlite, just like the way we specify the path to bookmarks.html via "browser.bookmarks.html"!
Flags: blocking-firefox3.1?
Using Firefox 3.0b5 on Fedora 9.
I'm on the same situation as Dennis McCunney.  In addition to sharing the same bookmarks file among several browsers, I also share it among different machines running Linux and Windows.
I decided to use mostly Firefox, instead of SeaMonkey, because I don't need the full package of suites provided by SeaMonkey (only the browser) and because Firefox seems to have some enhanced functionality.
Until FF2 I would use the one and same bookmarks file setting the browser.bookmarks.file string manually (rather laboriously, I should say, since every time I'd have to go after the instructions).  On Mozilla/SeaMonkey, on the other hand, it was simply a matter to open the bookmarks file on the bookmarks manager.  The sorting app provided by SeaMonkey is also more useful than FF.
Now, even that meager functionality is lost in FF3.

Could you please consider the possibility to restore this functionality to us?  Thank you.
(In reply to comment #3)
> Not blocking on this, as we're hoping to have better ways of doing this using
> the bookmark sync API.
> 
> Also, two users opening the same sqlite file will corrupt the DB.

it's not about x users/profiles accessing the places.sqlite at the same time, but about the possibilty that y users/profiles *could* access/share the same places.sqlite file (on different times).

if implemented the same way as in pre-Fx3 there would be no need to

- manually copy places.sqlite around profiles (local/remote)
- depend on/have to use any (online) sync providers

i guess it would not be a big deal to make this much demanded feature (votes/comments/forum threads) available for Fx3.next and give it some adequate developer resources - therefore nominating as 'wanted' in addition to the already given blocking request.
Flags: wanted-firefox3.1?
This is not a features I believe we will bring back as it was implemented in Firefox 2.  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...)

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.  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).  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.  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.  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.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: wanted-firefox3+
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1-
Resolution: --- → WONTFIX
(In reply to comment #21)
> This is not a features I believe we will bring back as it was implemented in
> Firefox 2.  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...)

Or we recognized the possibility of race conditions, and *didn't* open the same bookmarks file from more than one browser at a time.  I simply wanted all browsers to *use* the same file. A one line user.js file specifying the desired bookmarks file copied to each profile did the trick, and worked flawlessly.
 
> 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.  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).  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.  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.  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 fear I parse "consumer-oriented product" as "Joe User will shoot himself in the foot if we do implement this feature."  Perhaps, though I'm more optimistic than you are.  But how many folks use the FF2 workaround of specifying the bookmarks file to use in user.js?  I'd say a tiny fraction of users, even among the more technically competent and experienced who know what they are doing.  Most folks don't have a pressing requirement to have more than one browser share a bookmarks file.  And implementing the sharing at all requires knowledge about how stuff works.  Joe User won't have the knowledge, nor the need to acquire it, and is unlikely to shoot himself in the foot using a feature he doesn't know exists. 

I have a workaround I'm using here:  Browsers and profiles are all on the same file system, so I create a hard link to places.sqlite in each affected profile.  NTFS 5 will let me do that.  Life would be more complicated if I had Linux in the mix, but at the moment, that's not a factor.  It would be nice if I could do it entirely in the browser context with a config file, but if I have to go to the OS level, I can do that.  I might have problems if I tried to bring up more than one browser using places.sqlite at a time, but as mentioned, I don't do that.

Weave sounds useful for syncing across machines/OSes, but doesn't sound like it addresses the specific concern I raised.  I understand the WONTFIX, and will file an enhancement request at some point, but I think you are concerned about negative side effects that aren't likely to occur.  And if I *do* shoot myself in the foot, hey, that's *my* problem.  I use Firefox because it's the most powerful browser.  I don't want the dev team to decide *not* to implement a feature because I *might* shoot myself in the foot.  There's too much "lowest common denominator" software out there as it is.

(In reply to comment #22)
> (In reply to comment #21)
> > This is not a features I believe we will bring back as it was implemented in
> > Firefox 2.  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...)
> 
> Or we recognized the possibility of race conditions, and *didn't* open the same
> bookmarks file from more than one browser at a time.  I simply wanted all
> browsers to *use* the same file. A one line user.js file specifying the desired
> bookmarks file copied to each profile did the trick, and worked flawlessly.

It worked flawlessly, unless you forgot to close it on the other machine, and you'd lose data (bug 219772).  Or if you didn't have network when you started the app (Bug 251692).

It was never really designed for sharing, but that did work, usually.

> > 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.  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).  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.  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.  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 fear I parse "consumer-oriented product" as "Joe User will shoot himself in
> the foot if we do implement this feature."  Perhaps, though I'm more optimistic
> than you are.  But how many folks use the FF2 workaround of specifying the
> bookmarks file to use in user.js?  I'd say a tiny fraction of users, even among
> the more technically competent and experienced who know what they are doing. 
> Most folks don't have a pressing requirement to have more than one browser
> share a bookmarks file.  And implementing the sharing at all requires knowledge
> about how stuff works.  Joe User won't have the knowledge, nor the need to
> acquire it, and is unlikely to shoot himself in the foot using a feature he
> doesn't know exists. 

Its more on the level of "very few people will use this feature, and it wouldn't work very well at all if they did, so we're not going to spend time on recreating a crappy solution for a very small number of users."  Building a hacky solution to solve corner cases is not a good use of our time, nor is continuing to test and maintain said solution.  Just because a feature is hidden doesn't mean it won't have a cost in code size and complexity.  I think we already have too many hidden hacks, removing them is better than adding more, for the overall quality of the application.

> I have a workaround I'm using here:  Browsers and profiles are all on the same
> file system, so I create a hard link to places.sqlite in each affected profile.
>  NTFS 5 will let me do that.  Life would be more complicated if I had Linux in
> the mix, but at the moment, that's not a factor.  It would be nice if I could
> do it entirely in the browser context with a config file, but if I have to go
> to the OS level, I can do that.  I might have problems if I tried to bring up
> more than one browser using places.sqlite at a time, but as mentioned, I don't
> do that.

And if you did, and it blew up on you?  I suppose there's backups, but that seems pretty close to a "who needs airbags? I never crash my car" line.  There's a lot of bigger fish to fry here.

> Weave sounds useful for syncing across machines/OSes, but doesn't sound like it
> addresses the specific concern I raised.  I understand the WONTFIX, and will
> file an enhancement request at some point, but I think you are concerned about
> negative side effects that aren't likely to occur.  And if I *do* shoot myself
> in the foot, hey, that's *my* problem.  I use Firefox because it's the most
> powerful browser.  I don't want the dev team to decide *not* to implement a
> feature because I *might* shoot myself in the foot.  There's too much "lowest
> common denominator" software out there as it is.

Building a footgun is not in our mission statement.  We have many better things to do.

To be clear, the enhancement I mentioned was for having a "master" set of bookmarks for the schools/libraries/etc case.  We don't have a great solution for "locking" a profile at this time, and that's something that some people may want.  Read-only, not shared via hackery.
Flags: wanted-firefox3.1?
My typical use is: have different profiles at different PCs (notebook, work, home) which keeps different stored paswords and different configurations of addons etc.

BUT I had placed bookmarks.html on USB Flash drive which I carry over arond these different PCs.

I DO NOT WANT my bookmarks stored online somewhere, I DO NOT!

Please, allow to specify location of places.sqlite ... or find another way to store bookmarks on transferable drive without rest of profile, please.
I have found an alternative solution to keep your bookmarks.html file.

*** begin quote ***

The pref browser.bookmarks.autoExportHTML is false by default -- it
needs to be changed to true to have Fx 3 update the bookmarks.html file.

In earlier betas, it was true by default, so some beta testers may
never need to toggle it.


The bookmarks are the most important part of FF for me. So in the office I want to keep them on a network share for which the company runs a back-up.
I am fully aware of the issues regarding live-backups of DB systems. But it does not matter where I store the DB. It matters whether I remember to stop FF before the backup or not.
I used to share bookmarks.html between Linux and Windows on a dual-boot machine. This was only possible by relocating the file with browser.bookmarks.file in about.config.

Both use cases are broken now.

BTW: I personally don't need this, but I don't see what the problem is with sharing the new bookmarks DB among several users. While SQLite states that they lock the entire DB for an update, adding a bookmark is a short transaction and does not happen very frequently. DID YOU EVEN TRY IT? What were the actual problems you ran into?

Whatever you come up with, I think backup-up and also dual-booting are legitimate requests for a consumer-oriented product and I would appreciate it if that would be supported again. Protecting a product from accidental abuse is one thing. Preventing intervention of users entirely because "they are stupid anyway" is Microsoft style, the last thing I want to see in FF.

My backup problem described in comment #27 solves adequately with browser.bookmarks.autoExportHTML = "true". Nicely enough the export happens to the location specified in browser.bookmarks.file.

Now all I need is a browser.bookmarks.autoImportHTML and my dual-boot issue is solved, too :-)
I run Firefox on my desktop and laptop at home. Both machines use the same bookmarks file placed on a network share.

This means that I see the same bookmarks from which ever machine I am using and that the bookmarks are backed up along with my other data.

The new FF3 system breaks this completely and is clearly a regression for me.

If the decision is not to 'Fix' the issue please develop a system which allows me to replicate my FF2 set-up

Thanks
"If the decision is not to 'Fix' the issue please develop a system which allows
me to replicate my FF2 set-up."

Actually, that's a great idea: we get to use the really good speed demon Firefox 3 core while avoiding the resource-devouring database manager at the center of Places.

In the mean time, I shall not be using Firefox 3 for my routine work. And that allows me to continue to share my bookmarks.
Weave? http://labs.mozilla.com/featured-projects/#weave

It lets you synch between profiles on the same or different computer(s), or just back-up the info. If you're sufficiently a techie, I believe you can even set up your own local webdav server if you don't trust mozilla.org with your bookmarks.
Reposting the solution:

*** begin quote ***
The pref browser.bookmarks.autoExportHTML is false by default -- it
needs to be changed to true to have Fx 3 update the bookmarks.html file.

Thank you to Micheal Warner and Man-ai Chang for their comments and advice on work-arounds. This appreciated.

However I would come back to the basic point. FF2 uses a very simple bookmark file system which allows me to separate my data from my OS using a config edit, with all the benefits that this brings (sharing bookmarks on a network share and the ready back-up of the bookmark data).

FF3 implements a relatively complex database to manage bookmarks. The proposed benefits are centered around tagging and bookmark management. It does not appear to be possible to separate the data from the OS.

The workarounds suggested above involve setting up a weave account (which is still only v0.2 and hence not a stable release) or using the auto.export function.

The former adds yet another level of complexity to an already complex arrangement while the latter only adresses the backing up of bookmarks, not the sharing.

In summary for me the overheads of the new system far outweigh any benefits. My wish would be for a version of of FF3 which uses the FF2 bookmark system. While not being a programmer I can envisage having the bookmark system as a user selctable option.

Any thoughts ?
(In reply to comment #33)

> However I would come back to the basic point. FF2 uses a very simple bookmark
> file system which allows me to separate my data from my OS using a config 
> edit, with all the benefits that this brings (sharing bookmarks on a network 
> share and the ready back-up of the bookmark data).
> 
> FF3 implements a relatively complex database to manage bookmarks. The proposed
> benefits are centered around tagging and bookmark management. It does not
> appear to be possible to separate the data from the OS.

FF3 uses an sqlite database at the bookmark store.  Sqlite is cross platform, and *is* seperated from the OS.  The only thing you can't currently do is tell FF3 where to look for the place.sqlite file you want it to use.  (In my particular use case, separating it from the OS wasn't needed: I just wanted more than one Mozilla based browser to use the same bookmarks file, since I have FF, SM, NS, and Flock, and multiple FF profiles as well.)

Using sqlite offers all manner of interesting possibilities down the road, since it *is* a database, and can be queried with SQL statements.  I've found three different free GUI tools for Windows to examined and manipulate sqlite database, and one has even been made available as a FF3 extension.  You can use it to examine place.sqlite, since that is locked when FF is using it, but you can examine other databases in sqlite format FF3 maintains.
 
> The workarounds suggested above involve setting up a weave account (which is
> still only v0.2 and hence not a stable release) or using the auto.export
> function.

I use auto-export for back compatibility with older Mozilla based browsers.  It dumps the places.sqlite file to bookmarks.html, and the file is created where a user.js file in the profile directory says it's located.  That's one way, alas: updates I make in an older browser won't be propagated back to places.sqlite, but it works for my purposes.

And since NTFS supports links, I'm creating hard links to the places.sqlite file in the different FF3 profile directories.

That works fine, too, but will break if I add Linux to the mix.

At some point, I'll see if an NTFS symbolic link will allow me to put the places.sqlite file on a different drive.  Hard links must be on the same file system, but symlinks don't have to be.  If that works, it might even be possible to put the places.sqlite file on a network share.
 
> The former adds yet another level of complexity to an already complex
> arrangement while the latter only adresses the backing up of bookmarks, not 
> the sharing.

Not quite true.  See above.
 
> In summary for me the overheads of the new system far outweigh any benefits. > My wish would be for a version of of FF3 which uses the FF2 bookmark system. > While not being a programmer I can envisage having the bookmark system as a 
> user selctable option.

I wouldn't.  Too many interesting possibilities in having an actual database as the bookmark repository.  I have enough (my bookmarks.html file is 2.5MB) that I was considering ways to get it into a database for more advanced functionality.

All I want is a user preference in FF3 that will let me specify the location of places.sqlite, rather than requiring it to be in the profile directory.
 
> Any thoughts ?
 
Your best bet may be to stay put at FF2.
______
Dennis

> All I want is a user preference in FF3 that will let me specify the location of
> places.sqlite, rather than requiring it to be in the profile directory.

Yeah, lot of ppl want this, and AFAIK it is easily possible. As I read this thread, it will not be implemented, because, *IF* (say again, *ONLY IF*) used improperly (ie. sharing) , might result in errors in bookmarks/FF.

Mozilla FF devs thinks WE ARE NOT GOOD ENOUGH TO DECIDE. So, they decide for us what is better for us. Very Microsoftish :(


Take it to the forums or better yet, the newsgroups.  This bug is marked WONTFIX and bugzilla is not for discussing topics.
Maintaining two full history/bookmarks systems would be a massive amount of extra work for a dubious amount of benefit. It is not an option, period.
(In reply to comment #37)
> Maintaining two full history/bookmarks systems would be a massive amount of
> extra work for a dubious amount of benefit. It is not an option, period.

No one is asking you to. All that *is* being asked for is the ability to specify the *location* of the places.sqlite file, so that it does not have to be in the Firefox profile directory.  Why *shouldn't* it be on an network share?
______
Dennis


I'd like to clarify one of the technical reasons why the .sqlite file can't be put on a networked share using the current system. I'm not commenting on the value or lack thereof of keeping bookmarks in sqlite or combined with history, or Places in general: that's clearly a separate discussion. But a number of people are being insulting while misunderstanding the facts.

Sqlite uses a binary file format separated into pages. A program using it will cache pages of the file so they can be accessed quickly (you really want this or the whole browser will be very slow). Reading, caching, and writing all work on the granularity of the page (4K or so). Each page will contain a lot of different data, kind of randomly. When it updates something, all pages that were modified are re-written to disk, even though most of the data will often be unchanged.

Sqlite supports multiple readers and writers for the database at the same time. This was one of the reasons we started using sqlite in the first place: there was a desire to have more than one process be able to run on the same profile. However, it ended up not working out that well in practice.

Most importantly, some networked file systems in common usage lie about file locks. This means that multiple writers will stomp on each other, and will introduce inconsistent data in the database. This is not just the contents of the table cells, but the table metadata, so the database might not be readable any more. You can read http://www.sqlite.org/faq.html#q5 for more.

There is also a performance concern. If the browser has to re-read the history file from disk for determining the visited states of links on a web page, the entire browser will grind to a halt. For this reason, we keep the file locked which means that the data will be cached better. This may not be necessary any more: Firefox's system was designed when Sqlite's caching was more primitive than it is today, but that's why it is the way it is.

So, using the .sqlite files in your Firefox profile *at all* over a network share is actually kind of scary. However, since Firefox has a bunch of built-in profile locking for the profile separate from file locking, two things have to go wrong for you to get corrupted and it's not often an issue.

So if there were an option to specify the location of this file, and you ran on a networked file system that lies about locking or gets confused about it sometimes, as soon as you have two writers to the file, it will be immediately corrupted. Since many writes are done in the database as you browse, this happens pretty much all the time, and since the file format is binary, the corruption will likely be complete whereas with the html file you could probably fix it in a text editor.

Again, I'm not commenting on the goodness or badness of the current system, but this feature can definitely not be implemented as requested.
(In reply to comment #39)
> So if there were an option to specify the location of this file, and you ran 
> on a networked file system that lies about locking or gets confused about it
> sometimes, as soon as you have two writers to the file, it will be immediately
> corrupted. Since many writes are done in the database as you browse, this
> happens pretty much all the time, and since the file format is binary, the
> corruption will likely be complete whereas with the html file you could
> probably fix it in a text editor.
> 
> Again, I'm not commenting on the goodness or badness of the current system, 
> but this feature can definitely not be implemented as requested.

Thanks for the comment, Brett.  The technical reasons for why places.sqlite shouldn't be placed on a network share are a lot clearer, and I see why you wouldn't want to do that.

But it raises a question: Firefox Profile Manager will let you specify where to put a profile when you create one.  I have multiple FF profiles, customized for different uses, and make use of this.  I never liked the fact that the profile was created on Windows buried in the \Couuments and Settings\<username>\Local Settings tree, so I created a \Mozilla directory to hold Moz related stuff and places it under there in a Profiles directory. It makes keeping track, creating new instances, making changes, etc. a lot simpler when I have multiple versions of multiple products with multiple profiles in the mix.

So I have to wonder: what happens if you tell Profile Manager to create the whole *profile* on a network share?

I don't need to do that.  All *I* want to do is have multiple profiles share the same bookmarks.  Race conditions and "Which browser instance wins?" aren't problems because FF will only let me have one instance running at a time, and even if that weren't the case, I only *use* one at a time.  I just want changes I make in one profile available in the others.

I do that now under XP Pro with NTFS 5 by creating hard links to the desired places.sqlite file in the different profile directories.  It works fine. 

I just wish I didn't have to go outside of the browser to the OS level to implement it.
______
Dennis
> So I have to wonder: what happens if you tell Profile Manager to create the
> whole *profile* on a network share?

This is common for Linux users. At work, my home directory for Linux is over the network. That's what I meant when I was talking about the built-in profile locking separate from file locking. It creates a file in the profile directory that it checks for when it starts up to see if another copy is running.

(In reply to comment #41)
> > So I have to wonder: what happens if you tell Profile Manager to create the
> > whole *profile* on a network share?
> 
> This is common for Linux users. At work, my home directory for Linux is over
> the network. That's what I meant when I was talking about the built-in profile
> locking separate from file locking. It creates a file in the profile directory
> that it checks for when it starts up to see if another copy is running.

So for folks who want to have their bookmarks on a network share, creating the whole profile there is the best approach?

It still doesn't address the problem of making the same bookmarks file available in different profiles, but it's handy to know.

At the office, home directories for users on the multiple Linux servers are all on a back-end NAS array mounted via NFS on server startup, so I'm familiar with the concept.
______
Dennis  

Yea, we are definitely walking in circles here :( As I was stripped by chance to put bookmarks only on my USB Flash drive, I was forced (by devs!) to put whole profile on it. And nothing prevents user from putting it on network, if that is really an issue for which was disabled bookmark placement.

Not only devs did prevent what they want to prevent, they also achieved to hinder (for me having profile on slow usb drive) WHOLE PERFORMANCE of FF, because it now waits again and again for slow USB Flash drive working with whole profile there. Before that, I had profile on fast HDD and only bookmarks on USB, so it was running fullspeed. Now, in comparsion to FF3 with profile on HDD, FF is just crawling ... 

CONGRATS on that, devs. 

Dunno if new bookmark system is worth that, I see no difference between old and new bookmarks system ... but I definitelly grate my teeths every time I had to wait few seconds on quadcore system just for open new tab because of having whole profile on slow USB. The more as FF3 should be faster than FF2 ... for me it's slower like HELL just because I HAD TO have WHOLE profile on USB. And on Win system I cannot just hardlik bookmarks file because hardlink work only on same drive - I heard linuxies are luckier on that workarouding :/

Still, I stick with FF because I like it's modularity=ability to mold it to my likings. But I am on edge now, unfortunatelly :/

Only hope is devs will take in account that lot of ppl is unhappy with that and they will think this issue over ... this thread looks like some ppl will not let it sleep! You all have my support in that, folks, thanks for not being alone in that ...


Just correction, instead "Not only devs did prevent what they want to prevent" should be "Not only devs did *not* prevent what they wanted to prevent".
The new format is good if you really have many many bookmarks. But:

1. Why not XML but SQLite? Isn't XML more user-friendly and web-friendly?

I agree, that using "browser.bookmarks.autoExportHTML" is not the same as:

2. officially keeping bookmarks.html 
3. allowing user to select a different location for places.sqlite 

But then, if someone would produce an bookmarks add-on that do the 3 things, then the development team would not be blamed. :)

For me, I am happy with the good old bookmarks.html. It's pointless to keep so many bookmarks (to justify the use of a database format) that you, in the end, forgot to visit most of them after a few weeks, and have them *deleted*.

(In reply to comment #45)
> For me, I am happy with the good old bookmarks.html. It's pointless to keep so
> many bookmarks (to justify the use of a database format) that you, in the end,
> forgot to visit most of them after a few weeks, and have them *deleted*.

My exported bookmarks.html file is about 2.5MB.  I have enough that I was considering ways to import them into an actual database file well before Mozilla decided to use an sqlite file as the bookmarks repository.  You may not not see the need for that many, but Firefox here is a research tool and index into information.  Most of that information resides on the web in external sites, and FF contains the pointers to it.  Don't make the mistake of assuming that because *you* don't see a need for something, the need doesn't exist.

I'd like to be able to specify where it lives, but I have no problem with an sqlite file as the bookmarks repository.
______
Dennis

Thanks to Brett for providing technical details.

If I got it right, the situation is as follows:

1) Some network file systems can't handle file locking and the FF team decided to be on the safe side with this.
>Most importantly, some networked file systems in common usage lie about file
locks.

Write a big warning in the README and list the known faulty products. Even if a bug is common, it is still a bug and should be fixed in these file systems. Do not make this YOUR problem.

2) The same SQLite DB holds not only the bookmarks but a lot of other information for which there is a constant need of updating.

What would it mean to keep the bookmarks in an entirely separate SQLite DB?

3) Even for the bookmarks there is a constant need for updating the DB ("last visited", I guess?)

I know this is getting ugly, but: I have zero interest in keeping statistics of my personal bookmarks (I know which ones I am using). I would be very happy to give up statistical data collection for my bookmarks if in turn only relevant operations would cause a write operation in the SQLite DB (adding, updating or deleting actual bookmarks). Something like browser.bookmarks.doNotCollectStatisticalData.

I hope by separating update-intensive data from rather static data (bookmarks) and with the advance of SQLite a better solution can be implemented in the future.

BTW: "Weave" is NOT an alternative for me. I keep notes of passwords in my bookmark comments and do not want to share these over the Internet, no matter how "secure" the encryption is today.

All,

This thread seems to have created a great deal of interest. Reading through this and other posts the issue appears to boil down to how diferent groups use boomarks.

At one extreme we have users like Dennis (comment 34) who has 2.5MB of bookmarks and values the functionality that a database would bring. In comment 46 Dennis notes that he uses Firefox as a research tool and is used as an index to information, reinforcing his need for datbase functionality. I would characterise Dennis as a Power User. Returning to comment 34 he notes using the use of the auto export functionality of FF3 to maintain compatability with older mozilla products, but which is a one way street in terms of keeping the sq lite system and HTMl systems synchronised. 

Towards the other end of the spectrum you have user like me who have 50-60 bookmarks arranged into less than a dozen folders who value being able to keep our data (the bookmarks) on a different drive from the operating system and applications. This facilitates data sharing and back-up and soes not require the complexities of a database or the use of an external agent such a Weave.

While I accept that there may be evidence to the contrary I would suggest that my use is probably more representative of the majority of Firefox users.

The current FF3 set-up favours the Power User and disdvantages users like myself.

I am more than grateful that the the whole firefox project exists, the volunteer team giving us all a quality alternative to IE. However I am less than thrilled at the suggestion that I should forego the performance benefits of FF3 and stick to FF2 in order not to lose the functionality I currently enjoy.

If open source projects are about choice and alternatives I would ask, politely and respectfully, for the team to consider the development of one of two alternatives:

1. A version of FF3 which retains the FF2 bookmark system

2. A version of FF2 which uses the new core of FF3

Any thoughts ?

(In reply to comment #48)
> At one extreme we have users like Dennis (comment 34) who has 2.5MB of
> bookmarks and values the functionality that a database would bring. In comment
> 46 Dennis notes that he uses Firefox as a research tool and is used as an index
> to information, reinforcing his need for datbase functionality. I would
> characterise Dennis as a Power User.

Yes, I am.  But I'm not sure that's relevant to the discussion.

> Towards the other end of the spectrum you have user like me who have 50-60
> bookmarks arranged into less than a dozen folders who value being able to keep
> our data (the bookmarks) on a different drive from the operating system and
> applications. This facilitates data sharing and back-up and soes not require
> the complexities of a database or the use of an external agent such a Weave.

I wanted the same thing, but for a different reason.  I have multiple profiles, and multiple Mozilla based browsers installed.  I wanted all to use the *same* bookmarks file.

You can actually do what you want now with FF3.  You can't specify the location of the places.sqlite file.  You *can* specify the location of the profile directory when you create a profile in Profile Manager, and the whole profile can be on another drive.  So you not only back up your bookmarks - you back up the rest of your configuration as well.

> The current FF3 set-up favours the Power User and disdvantages users like
> myself.

> 1. A version of FF3 which retains the FF2 bookmark system
> 
> 2. A version of FF2 which uses the new core of FF3
 
> Any thoughts ?

It would be lovely if it were possible.  Unless you know someone with the skill and spare cycles to implement it, I don't see it occurring. The core Mozilla devs has other priorities.
______
Dennis


If this is really a won't fix, what about providing us with a very simple local weave server program that is small, very easy and convinent to install, and allow us to force our weave client to use our local server?

It'll then work exactly the same way as the weave idea except that we don't (shouldn't) have to login.



A local VERY light-weight Weave server would be acceptable. It MUST work without any connection whatsoever to the Internet: I also use the browser to read LOCAL HTML documentation, Java API for example, and DO have bookmarks to local HTML pages (file:).

> If this is really a won't fix, what about providing us with a very simple local
> weave server program that is small, very easy and convinent to install, and
> allow us to force our weave client to use our local server?

Hello,

I'm new in here so please forgive and correct any incorrect assumption. First of all I tried putting my 2 profile folders (linux and windows) on a common ntfs, and then created a hardlink. This worked but it only solves my specific case of dual boot (not the usb or database thing) and it's a dirty hack.

After reading on the new configuration folders, maybe it is possible to add a flag that would change the behaviour of the flag browser.places.importBookmarksHTML, in a way that once it is set to true, it STAYS at true (on the database it says "Import the contents of bookmarks.html into Places and set the preference to false"). Assuming that the browser.bookmarks.autoExportHTML flag exports to the SAME html file, this simple flag to code (probably 2 lines of code, correct me if I'm wrong) would solve our problem..

Please note that some problems were reported on the new inportBookmarksHTML : https://bugzilla.mozilla.org/show_bug.cgi?id=441177

Maybe this hasn't been implemented because the import functionality overrides everything setting satistics to zero, but if it only overrides bookmarks on places.sqlite properly, this should work right?

This would be an additional second at startup (just guessing) and would keep the "many users on same bookmark file" problem on the html file as before..

I'm new so please be gentle if I said nonsense on this post
(In reply to comment #52)

> I'm new in here so please forgive and correct any incorrect assumption. First
> of all I tried putting my 2 profile folders (linux and windows) on a common
> ntfs, and then created a hardlink. This worked but it only solves my specific
> case of dual boot (not the usb or database thing) and it's a dirty hack.

I use hard links under WinXP Pro SP3 because I want to use the same bookmarks file in several different profiles.  I just create a link in each applicable profile directory.

I also have older Mozilla based browsers that don't use places.sqlite that I want to use those bookmarks.  I set auto-export to HTML to true, and have a user.js file that specifies where the export gets placed, so the older browsers see the current set as well.  It's one way, since I'm not auto-importing as well, but I can live with that.

The issue I have is that hard link (on Windows or *nix can't span file systems, so all profiles must reside on the same filesystem.

Symbolic links might get around that, but NTFS doesn't support true symbolic links unless you are running Vista.
 
> After reading on the new configuration folders, maybe it is possible to add a
> flag that would change the behaviour of the flag
> browser.places.importBookmarksHTML, in a way that once it is set to true, it
> STAYS at true (on the database it says "Import the contents of bookmarks.html
> into Places and set the preference to false"). Assuming that the
> browser.bookmarks.autoExportHTML flag exports to the SAME html file, this
> simple flag to code (probably 2 lines of code, correct me if I'm wrong) would
> solve our problem..

The issue I can see with this is that you are then limited to only the information that can be stored in a bookmarks.html file, and it looks like places.sqlite is capable of rather more.  I'm not sure I'd care to live with the limitation. 
______
Dennis

Yes, I understand the issue of hard links on ntfs having to be on the same file system. Which is why I had to create my linux profile on an NTFS partition, and then hard link the windows places.sqlite to the linux one (or the other way around). That is why I consider this a dirty hack, since some day my linux distribution might manage in a wrong manner my NTFS partition, and then.. bye bookmarks. That is why my ideal situation would be to create both profiles in a FAT32 filesystem (or wherever I want). But this is not possible now since a hardlink is necessary now for the sqlite file, while before only a soft link would do the trick.

I don't agree much with your second comment though: Following Brett Wilson's explanations on Comment #39, on his third paragraph he states that "SQlite [..] ended up not working out (having more than one process run on the same profile)", While on the html file apparently it did work out.

That's why I understand your second comment as "If we can't have the hole thing, let's have nothing at all", while what I propose is a pragmatic and simple way of not breaking backwards compatibility and keeping the FF2 apparently useful fonctionality. Besides you are saying "I'm not sure I'd care to live with the limitiation" as if you never had this limitation before..

But I need someone from the "inside" to confirm if my assumptions are right: would it work this way? is it easily doable?
Just to add to all the use cases presented, I want to expose what we are facing.

We are using this typical setup (having the bookmarks in a different location) to share the bookmarks between windows, mac and linux machines. Of course, the bookmarks file is on a network device.

We are not talking here about isolated cases, but using this in a big infrastructure that runs for around 40 000 accounts (10 000 computers in a fiber network). Users log in on a machine (win, or lin, or mac), they open Firefox, they have their bookmarks. They go on another machine (cannot be logged in twice), open Firefox, still have their bookmarks.

As I understand from this bug report, there is absolutely no way of repeating that with FF3 , and will not be anyway to do that, except for using some sync way.

The problem is, in that case, we are not talking about different computers, we are talking about the same person (same account), on different machines. The home/My Documents/whatsoever personal folder of a user is in those cases always on the network, and it is never by choice as the user doesn't control this setup.

So, aside from just bringing back the feature in some way, what could be the way to do that ?

It is clearly a regression, and even if the software was not "intended" to do that, it permitted it.

And I know that Weave could be the solution, but not the way it is intended so, as we are talking about users that are in a corporate environment (using a product that is targeted for users), and are using Firefox as users. If we are going that path, I understand that, for an organisation to use Firefox widely on many computers/platforms, it will have to implement completely a local Weave server ?

My two cents.
(In reply to comment #55)

> As I understand from this bug report, there is absolutely no way of repeating
> that with FF3 , and will not be anyway to do that, except for using some sync
> way.
> 
> The problem is, in that case, we are not talking about different computers, we
> are talking about the same person (same account), on different machines. The
> home/My Documents/whatsoever personal folder of a user is in those cases 
> always on the network, and it is never by choice as the user doesn't control 
> this setup.
> 
> So, aside from just bringing back the feature in some way, what could be the
> way to do that ?

FF3 won't let you specify the location of the places.sqlite file.  That is hard wired to be in the profile used by that Firefox instance.  

FF3 Profile Manager *will* let you specify the location of the user's profile directory.  You can simply put *that* on the network share.

I do a variant of that because I don't care for the default behavior under Windows of creating profiles under the Documents and Settings\Application Data hierarchy.  I have multiple Mozilla products installed, with multiple profiles for several of them.  To ease maintenance, I created a \Mozilla directory on a drive, and directories below that to hold various things.  It looks like this:
\Mozilla
    \Bookmarks
    \Extensions
        \Firefox
            \2.0
            \3.0
        \Seamonkey
            \1.0
        \Thunderbird
            \2.0
    \Install Files
    \Plugins
    \Profiles
        \Firefox
            \2.0
                \Dennis McCunney
                \Development
        \Thunderbird
            \2.0
                \Dennis McCunney
                \Eudora
    \Themes
        \Firefox
            \2.0
            \3.0
        \Seamonkey
            \1.0
        \Thunderbird
            \1.0   

(There's more, but this gives you the idea.)

I use Firefox -p to get to the Profile Manager and create the desired profile.  In PM, I specify the name I want for the profile, and the location in the \Mozilla\Profiles tree where I want it created.

Another issue is that I want multiple browser progiles to use the same bookmarks file.  That requires hacking at the OS level.  NTFS5 supports hard links (and if you run Vista, symbolic links.)  I use a freeware program called Link Shell Extension, that makes it easy to create hard links in NTFS.  I simply drop a link to the desired master bookmarks file in each new profile directory I create, after I have created the profile, but before I launch the browser using that profile.  It works fine.

This does for FF3, but I still have things like FF2 and SeaMonkey installed that use the old bookmarks.html file.  That I can deal with within Firefox.

In the FF2 days, I created a user.js file that specified the location of the desired bookmarks file, and dropped a copy into each applicable profile directory.  If user.js exists, the browser will read it, and preferences specified in it will override what is in prefs.js.

FF3 has a preference called browser.bookmarks.autoExportHTML. If this is set to True, FF3 will export a copy of places.sqlite to a bookmarks.html file when you quit the browser. It obeys the specification in user.js for the location of the desired bookmarks.html file, and places the export there.  So the older browsers that still use bookmarks.html get the current set of bookmarks when I run them.

It's not two way syncing -- changes made in an older browser will not be propagated back the the master places.sqlite file -- but that issue arises seldom enough that it's not a problem.  If I see a site while in an older browser I want to bookmark, I just drag a link to my desktop, and add it the next time I'm in FF3.
______
Dennis 
Hi Dennis McCunney,

When you say "it's not two way synching", there might be a subtelty that could solve this problem:

As I explained on my comment #52, on FF3 there is a flag browser.places.importBookmarksHTML
which imports HTML bookmarks to the sqlite file. I assume this has been put there because of people upgrading from FF2 to FF3 not wanting to lose their bookmarks. That would also explain why this flag "Import the contents of bookmarks.html
into Places and set the preference to false" As explained in http://kb.mozillazine.org/Browser.places.importBookmarksHTML  .

So there IS a two way synching, except that this flag is set to False all the time. If this can be avoided I guess our problem (with all possible scenarios, multiple OS, multiple computers, multiple users, whatever) is solved, since we would replicate the behaviour of FF2 via an export/import to an HTML file. 

is someone able to confirm this?

thanks 
(In reply to comment #57)
> Hi Dennis McCunney,
> 
> When you say "it's not two way synching", there might be a subtelty that could
> solve this problem:

And indeed, it might be a solution, depending.

The problem is that places.sqlite appears to have the capability to store metadata that isn't in bookmarks.html, because bookmarks.html has no place to store it.  If that's the case, implementing two-way sync costs me the metadata.  I'm not sure that's a price I care to pay, when I use an older browser at best once in a while. 
______
Dennis

New foxes are always meant for the computer I don't have yet or don't prefer to use :). My profile is 282 MB and even if I had a memorystick which could store this, my poor old but favorite computer can only handle 1.1 USB so this would be slow like thick syrup.
I dual boot between Linux and Windows and not being able to share bookmarks stinks.  This certainly would be a nice feature to have again.
@Joe E

FF3 won't let you specifythe location ofthe places.sqlite file.  But you *can* specify the location of the Firefox profile using Profile Manager. I'd look at using Profile Manager to create a profile visible under both OSes.  (Offhand, it will be simpler to keep it on the Windows partition that the Linux partition.)  Create it under one OS, specifying the desired name and place it where you desire.  Then create it again under the other OS, using the same name, and specify the existing profile directory you created previously.

Poof!  Both FF instances will use the same profile, and therefor the same bookmarks file.  The major limitation I can see will be extensions, as a fair number aren't cross-platform. 
______
Dennis
@Dennis

Indeed, placing the profile on a shared mappable drive is a workaround. Of course, the issue remains that the profile is around 50MB and the old FF2 bookmarks.html file around 300K. Other people may have far bigger profiles.
For users that map a drive from home to the office (or uni in my case) this is feasible. The only negative point is that it takes around 30 seconds to start the browser and it works far slower than if it were merely the bookmarks file.
I may create a second profile which I will use for bookmarks and the rest of my settings locally. A bit awkward but the only way around this for now..
@sample1423

>Indeed, placing the profile on a shared mappable drive is a workaround.
>Of course, the issue remains that the profile is around 50MB and the old 
>FF2 bookmarks.html file around 300K. Other people may have far bigger 
>profiles.

Most of the 50MB profile size is the offline cache, and you can specify how big that should be in Options.  Though come to think of it, it would be nice if there were a preference that let you specify a local cache location for cases where the profile was on a mapped network drive.

One option might be to have FF clear your cache on exit (under Options/Privacy, check "Always clear my private data when I exit Firefox", and specify cache in the list of items to be cleared.)  I don't know offhand if this would affect the slow start up.  I suspect not: when you start FF it must enumerate and instantiate any add-ons and load your bookmarks, so one variable that affects how long FF takes to start up is the number of add-ons installed.  Back in the FF 1.X days, I had an experimental "everything *including* the kitchen sink" profile that had 115 extensions installed.  It was mostly to see if I *could* - in practice I used a smaller number.  But it took 45 seconds to fully load and initialize...  these days, I try to run a minimal configuration, and periodically go through the add-ons list to look for stuff I'm not actually *using* regularly. (My current config has 26 extensions installed, of which 9 are disabled.)

I formed the habit back when of invoking FF when I sat down at the machine and simply leaving it running, rather than exiting and restarting constantly as was the practice with IE.  Since FF is a layered product, and not an OS component like IE on Windows, it can't start as fast as IE can.  Older FF builds had memory leak issues that made that problematic, but FF3 seems to have pretty well resolved those.
______
Dennis
(In reply to comment #63)
> Though come to think of it, it would be nice if
> there were a preference that let you specify a local cache location for cases
> where the profile was on a mapped network drive.
http://kb.mozillazine.org/Browser.cache.disk.parent_directory ?
Our entire company was using Firefox but now we switched to IE8 because of this links issue.  Firefox is awesome but with out the option of moving the location of favorites to a network folder and having all browsers point to this location maintenance is too time consuming.  Foxmarks is one solution but we don't like it or use it.  There should be an option.
(In reply to comment #65)
> Our entire company was using Firefox but now we switched to IE8 because of this
> links issue.  Firefox is awesome but with out the option of moving the location
> of favorites to a network folder and having all browsers point to this location
> maintenance is too time consuming.  Foxmarks is one solution but we don't like
> it or use it.  There should be an option.

You can put the Firefox *profile* that contains the places.sqlite file on a network drive, and tell FF to use it.  It means everyone will have the same theme, extensions, etc., but for a corporate installation, I'd assume that would be what you want.

There's a prefix you can set to specify the browser cache location, so that can be on a local drive instead of the network drive, and it's probably what you'd want for performance reasons.  See comment 64 for the pointer to the Mozillazine article.
______
Dennis
> Our entire company was using Firefox but now we switched to IE8 
> because of this links issue....

If you google "firefox bookmark add-on" now, there are a lot of 
solutions! Anyway, it's way better to have about:config option
for that.
Thanks Dennis.  However, from what I have read online the places.sqlite file will become corrupt if multiple users access it.  I am not clear if this is if they access it read only or if they try to write at the same time.  We would have it as read only.  The other problem is that passwords and browser history would be shared between multiple users. In our case since it would be read only so no one could store there history or passwords.  

But then again that is why I thought the came up with using a db to store this information, so that users have quicker access to history.  With this work around, in our case of read only, there would be no way for to user to save bookmarks or browser history. Seems to defeat the purpose.  Again I think there should be an option like a plugin for people that want to use it.  I read somewhere online about: does history and bookmarks really get that that large that a database is required to manage it and I agree completely.  Seriously if someone had that many bookmarks and did not arrange them in some way that made sense they would end up using Google to find the information again anyway.
(In reply to comment #68)
> Thanks Dennis.  However, from what I have read online the places.sqlite file
> will become corrupt if multiple users access it.  I am not clear if this is if
> they access it read only or if they try to write at the same time.  We would
> have it as read only.  The other problem is that passwords and browser history
> would be shared between multiple users. In our case since it would be read 
> only so no one could store there history or passwords.  

Read only shouldn't be a problem.  Simultaneous *writes* might be, as it would be "last one wins".

> But then again that is why I thought the came up with using a db to store this
> information, so that users have quicker access to history.  With this work
> around, in our case of read only, there would be no way for to user to save
> bookmarks or browser history. Seems to defeat the purpose.  Again I think 
> there should be an option like a plugin for people that want to use it. 

As another option, you can have seperate profiles, rather than forcing all users to share the same one.

What OS is on the server?  NTFS 5 and Linux extfs both support "hard" links, so the same file can appear in more than one directory.  I do that here under XP, as I have several FF profiles and I want them to use the same bookmarks file.  After I create the profile, I link a copy of the master bookmarks file into it.  This must be done at the OS level rather than from withing the browser, but it works.

So you could create separate user profiles on the server, have a shared common bookmarks file, but other things like passwords separate, and use the previously mentioned preference to keep the browser cache on the user's workstation for performance reasons.

(This assumes you want everyone to have a standard common bookmark file, and *don't* want users adding their own.  If you do, just go with separate profles, and copy the standard set into a newly created profile instead of linking.)

> I read  somewhere online about: does history and bookmarks really get that 
> large  that a database is required to manage it and I agree completely.  
> Seriously if someone had that many bookmarks and did not arrange them in some 
> way that made sense they would end up using Google to find the information 
> again anyway.

The bookmarks file can get large: my places.sqlite file is about 38MB.  An export to an HTML file is a fraction of that size.

Management is always an issue.  I was thinking about an actual database to store FF bookmarks before FF3 implemented on in SQLite because of the number I had accumulated.  (Several thousand, though I haven't tried to count lately.)  FF is a research tool here, and my bookmarks file is a pointer to external references on a wide variety of topics.  I'm still training myself to add appropriate keywords when I bookmark a site, but I can generally find what I want.
______
Dennis
Here's a copy of what I just added to https://bugzilla.mozilla.org/show_bug.cgi?id=457109 .  There were bugs in 3.0.x that made the following solution unworkable.  It appears that those bugs have been successfully resolved in 3.5:

In case anyone else is searching for behavior to mimic the old 2.x
bookmarks.html behavior, try adding the following to your user.js (not
prefs.js) file:

user_pref("browser.bookmarks.file",
"path_to_bookmarks.html_with_doubled_backslashes");
user_pref("browser.bookmarks.autoExportHTML", true);
user_pref("browser.places.importBookmarksHTML", true);

By adding these settings to the user.js file, we ensure that they cannot be
modified by Firefox.  Specifically, this prevents Firefox from updating the
"browser.places.importBookmarksHTML" value to false.  Actually, it does change
it to false in the prefs.js file, but whenever Firefox opens it overrides that
value with the one in the user.js file, thus ensuring that the setting persists
indefinitely.

Observed behavior:
 * When Firefox exits, bookmarks.html is updated (based on autoExportHTML)
 * When Firefox opens, bookmarks.html is read and used to update existing
bookmarks
 * Tags and other Firefox 3 fringe benefits appear to persist through the
update process
 * The update process will both create and delete entries in the Bookmarks tree
 * If Firefox crashes (or is crashed by killing the process), the
bookmarks.html file does not get updated with any changes during that session,
and those updates will be lost when Firefox is next opened.  This is a
potential for loss of bookmarks.
 * If the bookmarks.html file is inaccessible when Firefox is started, it
leaves the existing bookmarks alone.
 * Standard "last Firefox to close wins" behavior seen in previous versions.

This provides a simple synchronization/backup mechanism for Firefox 3.5
bookmarks that largely mimics the 2.x behavior, with the exception that if
Firefox crashes after changes are made to the bookmarks but before Firefox
exits cleanly, those changes are lost.
(In reply to comment #70)
> In case anyone else is searching for behavior to mimic the old 2.x
> bookmarks.html behavior, try adding the following to your user.js (not
> prefs.js) file:
> 
> user_pref("browser.bookmarks.file",
> "path_to_bookmarks.html_with_doubled_backslashes");
> user_pref("browser.bookmarks.autoExportHTML", true);
> user_pref("browser.places.importBookmarksHTML", true);
> 

doesn't work for me on 3.6a2

btw the whole bookmark changes in ff3 ... i've some trouble making sense of them
grabbed a new nightly. now it works. more or less.
the html file now has half size which i don't care about BUT some entries are gone!
however using the html file i couldn't notice any difference so what's that new bookmarks format good for anyway?
(In reply to comment #70)

Please excuse spamming the bug tracker, I normally don't do this.  I would like to express my sincere thanks to Toby Ovod-Everett for pointing out how to resolve this issue, and confirm that the work-around works great!

It just simply blows my mind through which hoops one has to jump to in order to integrate syncing of firefox bookmarks into an already existing and robust file synchronization and backup workflow.  

Synchronization is a standard and well-solved problem which any serious user has to figure out anyway, so it seems to be extremely bad policy that firefox keeps typically small amounts of highly valuable bookmark data hardwired into the profile directory which also contains cache, history, extensions, and other temporary data which is typically not worth synchronizing and possibly not even usable across different browser versions.   Firefox does not need to reinvent the wheel, all it needs to offer is a transparent interface (like the bookmarks.html file provides) to export and import this small amount of nonvolatile user data. (OK, passwords could be another category of nonvolatile data possibly worth exporting, but whether I want to store or spread that information around as widely as possible is a whole other issue...)

Since Firefox 3 was included into Fedora, I wasted hours looking at bookmark synchronization extensions, but all I found seems complete overkill, usually requiring the setting of a separate server (or using third party servers of unknown reliability, security, and longevity).  

Today, finally finally, after two hours of googling I got to comment #70 in this issue.  And the solution is right there, as simple as obscure, the official firefox crowd apparently in denial about its existence.  "WONTFIX" - I can't believe it.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h".

In Thunderbird 3.0b, you do that as follows:
Tools | Message Filters
Make sure the correct account is selected. Click "New"
Conditions: Body   contains   places-to-b-and-h
Change the action to "Delete Message".
Select "Manually Run" from the dropdown at the top.
Click OK.

Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter.

Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
(In reply to comment #70)
> In case anyone else is searching for behavior to mimic the old 2.x
> bookmarks.html behavior, try adding the following to your user.js (not
> prefs.js) file:
> 
> user_pref("browser.bookmarks.file",
> "path_to_bookmarks.html_with_doubled_backslashes");
> user_pref("browser.bookmarks.autoExportHTML", true);
> user_pref("browser.places.importBookmarksHTML", true);
> 
Several comments on this, I'm not sure what "doubled-backslashes" are about, they are not used other than in Windows, and last time I checked Windows was happy to take forward slashes. Also, is it required that the name be bookmarks.html, or is that convention?

In any case, this doesn't seem to work in Linux (Build 20101115010742) and using it causes the messenger window to crash. Screen dumps at http://goo.gl/gVqFc if anyone cares (didn't work regardless of name).

Just for documentation, I get the WONTFIX loud and clear
You need to log in before you can comment on or make changes to this bug.