282490 - Prexisting bookmarks.html file is overwritten while using about:config to change the default folder location

Status: RESOLVED DUPLICATE of bug 259238

(Firefox :: Bookmarks & History, defect)

Description

[ljbmailprotect-mozilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I was using the tip found at: http://mozilla.org/support/firefox/tips#beh_bookmarks
to specify a bookmarks.html file to use other than the default except that I
used about: config to edit the "browser.bookmarks.file" setting rather than
creating a user.js file.
Note that the reason I needed to do this is that I have a dual boot system with
Firefox installed on both W98SE and XP and I wanted them to use the same
bookmarks file.
After installing firefox on XP I went to about:config to change the location of
the bookmarks file.  Instead of immediately using the existing bookmarks.html
file located in the W98 location firefox overwrote that file with the default
bookmarks.html file from the XP installation default folder location.  In other
words it does a copy and replaces the existing file prior to using the specified
new folder location for the bookmarks file.  In fact, it overwrote the backup
bookmarks file too causing complete loss of bookmarks data if not previously
backed up!

Reproducible: Always

Steps to Reproduce:
1. have pre-existing bookmarks.html file in another folder
2. type about:config and change "browser.bookmarks.file" location to that in #1
3. exit and reload firefox

Actual Results:  
Firefox does a copy of bookmarks.html from the default location to the new
location and replaces the existing file prior to using the specified new folder
location for the bookmarks file.  In fact, it overwrote the backup bookmarks
file too causing complete loss of bookmarks data if not previously backed up!

Expected Results:  
Firefox should not copy over or delete any EXISTING bookmarks.html files. 
Instead, when changing the "browser.bookmarks.file" location it should simply
start using the existing file in that location.  If no file exists in that
location THEN and ONLY THEN would it be OK to perform the copy operation it
currently does.

Comment 1

[Mike Connor [:mconnor]]

*** This bug has been marked as a duplicate of 259238 ***

Comment 2

[ljbmailprotect-mozilla]

Yes this is a duplicate of bug # 259238.
But I don't agree with the resolution of 'won't fix'.

From Vlad's comment copied below on how firefox reads and writes the bookmarks
file it seems to me that there is an easy fix for this that should satisfy
everyone.  All you have to do is have firefox re-read the bookmarks file from
the new locaton whenever the "browser.bookmarks.file" pref is changed just like
it does at browser launch.  If there is an existing file it will be read in and
all data will be preserved.  If there is no existing file in the new location
then firefox can behave as it currently does, no new file is read and the
current bookmarks in memory are written to the new location.

The following comment was copied from duplicate bug # 259238
============================================================
 ------- Additional Comment #1 From [e-mail]  2004-09-14 14:09 PST 
[reply] -------

Now that mconnor pointed out some things to me.. the bookmarks file is
write-only during a session, and is only read at browser launch.  Changing this
(hidden) pref during a session will only cause bookmarks to be written there; so
it's normal that what was there was overwritten the next time bookmarks were
saved.  If you'd like to have this behaviour, you can edit user.js before you
launch the browser.  Note also that if you have mozilla and firefox pointing to
the same bookmarks file, and you use them both at the same time, any bookmarks
changes in one will get overwritten by the other.

-> WONTFIX, sorry

Comment 3

[Mike Connor [:mconnor]]

You can disagree all you want, but we're not going to fix this, partly because
your simple solution isn't a global solution, since it doesn't address what to
do with bookmark changes since the beginnning of the session.

Comment 4

[ljbmailprotect-mozilla]

Isn't it obvious to any user that if you are replacing the bookmarks file that
Firefox is pointing to with another that you don't intend to use the current
file and any changes that you have made to it since the beginning of the session
can be discarded????

Comment 5

[ljbmailprotect-mozilla]

Also, one more plea to fix this bug:
Many users including myself have experienced complete loss of large bookmarks
files representing many hours of work.
This is serious enough that some solution should be implemented.
Doesn't have to be mine.

Comment 6

[Wolf [:wolf]]

Both Vlad and Mike Connor are Firefox peers, this bug is wontfix.

Rationale for the wontfix seems pretty clear to me, pasted here from Bug 259238
Comment #1, in Comment #2 here.. and Comment #3.

You're changing the bookmarks location, IMO, i'd expect the current bookmarks to
be saved there, which sounds like what's occuring. Why are you pointing it at a
pre-existing file if you don't want it overwritten with Firefox's bookmarks? :-)

--> WONTFIX.

Comment 7

[ljbmailprotect-mozilla]

(In reply to comment #6)
> You're changing the bookmarks location, IMO, i'd expect the current bookmarks to
> be saved there, which sounds like what's occuring. Why are you pointing it at a
> pre-existing file if you don't want it overwritten with Firefox's bookmarks? :-)
> 
> --> WONTFIX.

If you read my suggestion in comment #2
https://bugzilla.mozilla.org/show_bug.cgi?id=282490#c2
you can easily do it both ways in the same code, in other words copy the
bookmarks as it currently does if no file exists in the new location and don't
copy if a file already exists.

To answer your question about why I am pointing bookmarks at a pre-existing file:
There are many potential reasons why you might want to do this.  In my case, I
have dual boot system with firefox already installed in another partition.  On
my new OS install in a 2nd partition I also installed firefox but wanted the two
 firefox installations to use the same bookmarks file.  I simply pointed the 2nd
firefox to the first one's bookmarks file expecting it to use that file. 
Instead it overwrote that file and its backup with the default bookmarks
installation which is nearly empty.  This is totally unexpected behavior!  The
first time this happened to me it caused a loss of hours of work restoring
bookmarks from backups and manually recovering any new additions.  The way
firefox currently handles this situation is without any 'intelligence' at all as
it does the same thing wether the new file location exists or not!

Another potential reason someone might do the same thing is creating a
multi-user system in XP where the users share a common bookmarks file. 
Additionally, on a single user system you might have multiple bookmarks files
and want to switch between them (the old Netscape 4.78 had that functionality in
the UI).

Again, my suggestion in comment #2 would fix this and 'intelligently' maintain
the current process.  When you define a new bookmarks file and location check to
see if the file already exists.  If it doesn't proceed as it currently does
copying the current bookmarks file to the new location.  If it does ALREADY
EXIST YOU SHOULD ASSUME THAT THE USER WANTS FIREFOX TO USE IT AS THE BOOKMARKS
FILE and just use it rather than blatantly overwriting it and destroying the
data.  I maintain that the CURRENT PROCESS marks a WRONG ASSUMPTION that if a
bookmarks file exists in the new location that you want it overwritten with the
current bookmarks.  Who would EVER want that???

Comment 8

[Wolf [:wolf]]

at the risk of being drawn into further argument here.. The "wrong assumption"
you give maintains users current bookmarks, as obvously, they're not expecting
them to vanish mysteriously by changing that pref. Multiple locations sharing
the same bookmarks file is unsupported, and results in atomic updates and
corruption. The idea behind the behavior is to maintain the loaded bookmarks at
the new location. Makes sense to me.

Comment 9

[ljbmailprotect-mozilla]

(In reply to comment #8)
> at the risk of being drawn into further argument here.. The "wrong assumption"
> you give maintains users current bookmarks, as obvously, they're not expecting
> them to vanish mysteriously by changing that pref. Multiple locations sharing
> the same bookmarks file is unsupported, and results in atomic updates and
> corruption. The idea behind the behavior is to maintain the loaded bookmarks at
> the new location. Makes sense to me.

Yes and what I propose would also maintain users current bookmarks.  Further as
you descibed it is undesirable and I say unexpected for the bookmarks file to
mysteriously vanish by changing that pref.  This is exactly what currently
happens IF you point the location to an existing bookmarks file.  It gets
overwritten by the current bookmarks and is gone for good.  It happened to me
twice! but now I keep it backed up.

I'm just asking for a little intelligence to be put into firefox here.  Part of
what is a 'wrong assumption' is that the new location of the bookmarks file is
always going to be fresh and contains no file therefore the current bookmarks
needs to be copied there.  This is not always the case!

Why don't you put a little intelligence into firefox and check to see if the new
location being pointed to by "browser.bookmarks.file" already contains a valid
bookmarks file before doing anything?  If it doesn't go ahead and copy current
bookmarks there as it does today.  If it does, load the bookmarks file and start
using it as the current bookmarks.  This makes even more sense to me, would make
everyone happy and would eliminate firefox's unexpected behavior and loss of
data under BOTH circumstances.  

In regard to your comment about 'atomic updates and corruption' this should not
occur or be a problem as long as the bookmarks file is not being SIMULTANEOUSLY
accessed.  For instance, in the multi user XP scenerio I mentioned, one user
logs on and logs off before a second user logs on but both users share the same
bookmarks file.  Or in my case with a dual boot system you can only use the
bookmarks file from one OS at a time.  If you want simultaneous access you have
to maintain separate bookmarks files under separate user accounts.

I honestly can't understand why you guys are being so adverse to this suggested
change.  Its a very simple change and would benefit a lot of users.  It also
makes firefox act consistently wether the change is made through about:config or
through the user.js file user_pref("browser.bookmarks.file").  Maybe you hadn't
considered that firefox is currently acting inconsistently by handling this
parameter change two different ways wether the change is made trough
about:config or the user.js file.  What's worse is that the online documentation
leads one to believe that you can make this change either way and the same thing
will happen and this is wrong.  At the very least the documentation should be
corrected to warn users about the differences but it would be better to make the
change and make firefox consistent either way.

Comment 10

[ljbmailprotect-mozilla]

I found other users complaining about the exact same data loss behavior except
when sharing bookmarks between firefox and Mozilla.
See Bug 219772 Comment #4 

Since that bug was listed as an open enhancement request I am reopening this bug
as an enhancement also since they are related.  

With multiple people complaining about the same behavior won't you PLEASE
consider making a change to Firefox?

Comment 11

[Mike Connor [:mconnor]]

Please stop reopening this bug.  As reported, its anything but an enhancement,
and its almost unusable as an enhancement bug to change the response to changing
the pref.  Morphing bugs is discouraged, since it makes actually fixing bugs far
more difficult since the report becomes bunched up and incoherent.  We
considered it, and decided against it.  Implying that we didn't really isn't
productive either.

To fix this "right" the way you're suggesting, if the pref changes, and there's
an existing bookmarks file, we'd have to drop all current bookmarks and reload
the new bookmarks file immediately.  So if a user bookmarks something, then
changes the pref, they'll lose that bookmark.  The only other option is to
somehow track bookmarks added in the current session, and merge those into the
new bookmarks tree, somehow, and that's even more of a bloat situation than just
adding a pref observer and some basic presence checking.

To be honest, I'd rather drop support for the pref than add code to support
changing on the fly.  Or, alternatively, make changing the pref have no effect
except on startup.  This is a hidden pref inherited from Mozilla that seems to
cause more problems than benefits.  It doesn't allow proper sharing, yet people
think it will.  In an end-user focused design, it doesn't have a lot of value
especially as compared to sharing an entire profile.

*** This bug has been marked as a duplicate of 259238 ***

Comment 12

[ljbmailprotect-mozilla]

(In reply to comment #11)

> To fix this "right" the way you're suggesting, if the pref changes, and there's
> an existing bookmarks file, we'd have to drop all current bookmarks and reload
> the new bookmarks file immediately.  So if a user bookmarks something, then
> changes the pref, they'll lose that bookmark.  

Yes your statement above is exactly what I am suggesting.  Of course, you could
write the current bookmarks file out before reloading with the new bookmarks
file in order to prevent that loss too.

> 
> To be honest, I'd rather drop support for the pref than add code to support
> changing on the fly.  Or, alternatively, make changing the pref have no effect
> except on startup.  This is a hidden pref inherited from Mozilla that seems to
> cause more problems than benefits.  

I actually LIKE YOUR SUGGESTION to get rid of the pref and make it only
changeable on startup!  As long as firefox does not try to do any copying of
files on startup!!  It should simply use whatever bookmarks file is pointed to
on startup.  If the file doesn't exist then an empty file should be started.  If
the user wants to have the old bookmarks file copied to the new location let him
do that manually outside of firefox before startup.

This is simple and would resolve all of these issues and inconsistencies with
how firefox behaves differently when the bookmarks file is changed on startup
vs. dynamically.

BTW, I don't understand why you are keeping Bug 219772 open as an enhancement if
you keep shutting this one down?  It is even more complex than what I suggested.

Comment 13

[Mike Connor [:mconnor]]

Because in the future, we could move to something vastly different in how we
store bookmarks.  Doing things in RDF doesn't scale well, so really big
bookmarks files are a big perf drag.  At some point, we'll want to replace the
current implementation with something a bit more robust.  But that's far-future
type, this is more in the now.

I'll file a bug later on to make the bookmark location only read at startup. 
Its the only sane way, and I'm only even keeping the pref around because I'm not
about to write migrator code to pull in the old bookmarks into a new file.

Someday, we can really kill it. :)

Comment 14

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change