Last Comment Bug 157152 - read-only/hidden bookmarks.html (or bookmarks.html.moztmp) causes creation of bookmarks-{n+1}.html
: read-only/hidden bookmarks.html (or bookmarks.html.moztmp) causes creation of...
Status: RESOLVED INVALID
[2012 Fall Equinox]
: helpwanted
Product: SeaMonkey
Classification: Client Software
Component: Bookmarks & History (show other bugs)
: Trunk
: All All
: -- normal with 11 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://forums.mozillazine.org/viewtop...
: 189651 193141 244245 248651 273576 283243 363416 (view as bug list)
Depends on: 257288 368317
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-12 09:57 PDT by rcummins
Modified: 2012-09-22 06:38 PDT (History)
24 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
delete temp file if moveto fails because of accessdenied (743 bytes, patch)
2004-06-27 18:22 PDT, timeless
no flags Details | Diff | Splinter Review

Description rcummins 2002-07-12 09:57:41 PDT
I installed Mozilla on a PC available to the general public.  As was traditional
with Netscape Communicator, I set bookmarks.html to read-only so people couldn't
(permanently) fiddle with bookmarks or personal toolbar items.  Today I have 479
bookmark files: bookmarks.html, bookmarks-1.html, bookmarks-2.html ...
bookmarks-477.html, and bookmarks-478.html.  Funny thing is, they're all
identical in content.

Having Mozilla write bookmarks-1.html when it can't write to bookmarks.html
isn't a bad idea, but writing bookmarks-{n+1}.html when bookmarks-{n}.html is
the same darn file just because bookmarks.html is read-only (and BTW is already
identical to both bookmarks-{n}.html and bookmarks-{n+1}.html) IS a bad idea.

IF Mozilla can't write to bookmarks.html AND bookmarks have changed, THEN
Mozilla should (maybe) create bookmarks-1.html.

IF Mozilla can't write to bookmarks.html AND bookmarks have NOT changed, THEN
Mozilla should (definitely) not create bookmarks-1.html

IF bookmarks-{n}.html exists AND bookmarks.html is read-only, THEN Mozilla
should (maybe) create bookmarks-{n+1}.html but only IF its content would differ
from bookmarks-(n}.html

(Of course, to me the behaviour of NC which was just not to write bookmark.html
if it was read-only is ideal, but I guess the bookmarks-1.html business is in
Mozilla for a reason.)
Comment 1 Chris Lyon 2003-02-16 08:46:22 PST
*** Bug 189651 has been marked as a duplicate of this bug. ***
Comment 2 Chris Lyon 2003-02-23 21:36:44 PST
*** Bug 193141 has been marked as a duplicate of this bug. ***
Comment 3 rcummins 2003-04-16 10:47:36 PDT
Using build 2003041504, and setting bookmarks.html to read-only, I see only a
single bookmarks.html.moztmp being created, vs. the ever-increasing number of
bookmarks-{n}.html that I reported earlier.  I'd like to resolve this bug but
I'm not sure whether to mark it "FIXED" or "WORKSFORME"...
Comment 4 Morbus Iff 2003-04-16 10:54:17 PDT
Unfortunately, I'm still able to duplicate it. Using 2003040105 (the 1.4a),
marking the file RO, then adding a new entry caused bookmarks-1.html and
bookmarks-2.html to be created upon window closing. I'll see if I can yank down
a nightly and duplicate.
Comment 5 Morbus Iff 2003-04-16 11:12:13 PDT
Confirming the .moztmp behavior on 2003041609 - what seems to happen is that if:

a) I make the file RO.
b) I add a bookmark.
c) A .moztmp is created.
d) The RO flag is stripped.

As long, however, as the .moztmp file exists, the original bookmarks.html file
doesn't seem to be utilized, even though it's been stripped of RO.
Adding/deleting/modifying bookmarks has no effect. Removing the .moztmp file and
adding/deleting/modifying in bookmarks.html takes effect again (ie. is saved
correctly).
Comment 6 R.K.Aa. 2004-06-25 11:51:56 PDT
*** Bug 248651 has been marked as a duplicate of this bug. ***
Comment 7 Brendan Eich [:brendan] 2004-06-25 19:06:17 PDT
Timeless fingers suspect code in nsLocalFileWin.cpp.  Cc'ing buddies.

/be
Comment 8 timeless 2004-06-27 18:22:14 PDT
Created attachment 151834 [details] [diff] [review]
delete temp file if moveto fails because of accessdenied

note that i believe there is bogus code in both xpcom/io and bookmarks (and of
course xpcom/io/nsIFile.moveTo[Native] is underspecified).

the bad bookmarks code is the if at:
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp&rev=1.319&mark=5530,5531#5530>
i need to special case certain failure code(s).

this bookmarks patch is based on the following assertion:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsIFile.idl&rev=1.61&mark=178-179#165


should be changed to say that it will throw
NS_ERROR_FILE_ACCESS_DENIED if 'this' is a readonly like file. (Reasons could
be the file is |attrib +r|,|chmod -w|,|cacls /e /p user:r| or the file is owned
by someone else and not o+w)

This patch is not very useful w/o a fix in xpcom/io to return the
NS_ERROR_FILE_ACCESS_DENIED error result (and of course that code has to be
nice and *must* leave the original file in place instead of simply
trashing/losing it.
Comment 9 timeless 2004-06-27 18:34:41 PDT
The following url encodes the codepath through nsLocalFileWin for this bookmarks
problem:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileWin.cpp&rev=1.126&mark=2196,2199,2203,1190,1192,945,1077-1082,1023,839,882,884-885,907,927#882

With one exception: 1077-1082 which is code we need on a road not taken. If the
code path we followed included code like that that then things might be happy.
Comment 10 Darin Fisher 2004-06-28 13:48:25 PDT
cc'ing brodie since he likes playing with nsLocalFileWin issues ;-)
Comment 11 jay c box 2004-07-23 13:23:08 PDT
I installed 1.8-a2 and deinstalled it when the problem materialized.
I installed 1.7.1 and the problem is still there.

bookmarks-NNNN.html

I am watching the profiles/default/... direcotry with my bookmarks.html file and
its adding a new copy every 15 seconds.

I checked to see if the bookmarks faile was read protected, it is not. None of
the ascending directories are read only either.

Well it just barfed when I pressed the [ COMMIT ] button same nonsense about the
OS selection being changed. Fine, you win... i have W95 but your form wants to
call it Win2000. Great... Maybe I'll have 2000 bookmarks when I get this to load.

I discovered the problem being bookmark files after noticing the new 1.8 froze
every 8 seconds and unfroze for 8 seconds in a continual duty cycle. When I
tried to report this early today, the bug report through me out because it
wanted OS2 selected and I didn't. Threw the whole computer and mozilla out the
window... or did I just consider it?

This morning the 50% duty cycle was 13 second on and 13 seconds off... While
searching to save my bookmarks file before deinstalling, I found 636 copies in
the mentioned directory.

I read a lot of the reports with similar problems in other versions but its very
much alive on my computer.
Comment 12 dwitte@gmail.com 2004-07-29 22:07:37 PDT
fixed by proxy of bug 252193. if the file is readonly, it won't be overwritten
and no bookmarks will be saved.
Comment 13 rcummins 2004-08-20 07:13:20 PDT
Reopening, as this problem still exists in the latest nightly (Win2000,
2004081908).  If bookmarks.html is read-only, Mozilla will create
bookmarks.html.moztmp (if it doesn't already exist) which is apparently a copy
of bookmarks.html and is also read-only.  When Mozilla closes, it creates
bookmarks-1.html *and* bookmarks-2.html, and two more sequentially numbered
bookmarks-{n}.html files for every subsequent time Mozilla is exited.

I notice also that prefs.js, when read-only, behaves similarly, except Mozilla
creates only one prefs-{n}.js when it exits.
Comment 14 Peter Weilbacher 2004-12-01 01:42:46 PST
*** Bug 244245 has been marked as a duplicate of this bug. ***
Comment 15 Felix Miata 2004-12-07 10:30:01 PST
*** Bug 273576 has been marked as a duplicate of this bug. ***
Comment 16 Felix Miata 2004-12-07 10:31:27 PST
Changing OS to all: 1 dupe from XP & 1 dupe from OS/2.
Comment 17 Scott Field 2004-12-28 15:11:11 PST
Also occuring in Mac OS X in suite 1.8a6 build 2004122706 and Firefox 1.0+. 
Started occuring several months ago after the problem with the bookmark file not
being saved was fixed, thought this might have been the fix. At that time I had
locked my bookmark file but I have since unlocked it.  Also tried creating a new
profile without bookmarks and still had problem
Comment 18 Brendan Eich [:brendan] 2004-12-28 16:38:19 PST
Cc'ing vlad in case this has anything to do with the bug he mentioned on IRC the
other day.

dwitte, if you're not able to hack on this, can you get someone else to take it?

/be
Comment 19 Dan M 2005-01-13 10:52:35 PST
Why patch one symptom of a basic flaw when you could fix the flaw itself,
described in bug 257288?
Comment 20 Martin Sch 2005-01-19 13:51:24 PST
Very annoying bug. The last days, my PC was slow and working hard on the disk.
Now I found that there were thousands of bookmark files, and the original one
was hidden. I have firefox 1.0.
Comment 21 OstGote! 2005-02-08 02:36:40 PST
See Firefox Bug 281359 there a read-only bookmarks.html.moztmp caused this
behavior. I guess this is due to the copy function, see comment 13, and later
the file bookmarks.html was writable again but not the copy.
Comment 22 OstGote! 2005-02-14 06:53:46 PST
See Bug 271883 for a patch to fix the problem for hidden files.
Comment 23 Piper 2005-02-24 21:53:48 PST
Added my vote for this bug, with suggestions: 

1. If any file (bookmarks, cookies, profile...) is R/O, Mozilla should simply
return and NOT create any new files. This will allow running Mozilla from R/O media.

2. Updating Bookmarks "LAST-VISITED" should be a user-controlled option. Not
updating the bookmark file every 10 secs would improve performance and lessen
the stress on disk/Flash media, which Mozilla hits TOO often.

pipr1
Comment 24 OstGote! 2005-07-20 11:18:30 PDT
*** Bug 283243 has been marked as a duplicate of this bug. ***
Comment 25 Frankie 2005-11-17 08:11:29 PST
Two quick questions:

1: is there a separate bug for the same issue in Firefox, or does this cover both?

2: does a workaround exist for OSX? What permissions/user/group does Firefox run as? If I chmod/chgrp the files to match, will the problem go away?
Comment 26 Tom Hessman 2005-11-17 11:56:32 PST
I've seen this issue for a really long time on OS X now, and as far as I know my bookmarks file has never been read only.  I tried to fix it by making a new profile at one point, and then importing my old bookmarks through the bookmark manager, but the problem continued!  It seems to write a new file every time I close Firefox.  I'm now up to bookmarks-1176.html...
Comment 27 Tom Hessman 2005-12-19 15:36:38 PST
What's the status of this bug?  I'm now up to bookmarks-1283.html on my Mac, causing my profile to be about 357.6MB!  Is it safe to delete those files without affecting my bookmarks?  I haven't tried creating a new profile for a while (though I will soon), but the last time I did it started happening again once I imported my old bookmarks...and as far as I know none of the bookmark files have ever been read-only.
Comment 28 Ben Fowler 2005-12-19 23:18:54 PST
(In reply to comment #27)
> What's the status of this bug?  I'm now up to bookmarks-1283.html on my Mac,
> causing my profile to be about 357.6MB!  Is it safe to delete those files
> without affecting my bookmarks?  I haven't tried creating a new profile for a
> while (though I will soon), but the last time I did it started happening again
> once I imported my old bookmarks...and as far as I know none of the bookmark
> files have ever been read-only.

See Bug 294584 "Spotlight contention with bookmarks.html causing multiple 
backups?"

Yes, you are O.K. to delete them.
Comment 29 Tom Hessman 2005-12-20 00:13:04 PST
(In reply to comment #28) 
> See Bug 294584 "Spotlight contention with bookmarks.html causing multiple 
> backups?"

Great tip...that was the issue for me!  I configured Spotlight not to index my profile and it stopped, so I cleaned up my bookmark files and it still wasn't happening anymore!  For those of you seeing this on Tiger (Mac OS X 10.4) I suggest you check out bug 294584.  It's basically a special variation of this bug...

Unfortunately I can't remember for sure whether or not this started before I upgraded to Tiger...but this stopped it.
Comment 30 Marcin Drozdowski 2006-12-11 00:43:17 PST
*** Bug 363416 has been marked as a duplicate of this bug. ***
Comment 31 dwitte@gmail.com 2007-06-26 18:31:26 PDT
-> default owner, helpwanted
Comment 32 Phoenix 2012-09-22 06:38:41 PDT
With moving to Places this bug became obsolete, closing

Note You need to log in before you can comment on or make changes to this bug.