Closed Bug 157152 Opened 22 years ago Closed 12 years ago

read-only/hidden bookmarks.html (or bookmarks.html.moztmp) causes creation of bookmarks-{n+1}.html

Categories

(SeaMonkey :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: rcummins, Unassigned)

References

()

Details

(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox])

Attachments

(1 file)

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.)
*** Bug 189651 has been marked as a duplicate of this bug. ***
*** Bug 193141 has been marked as a duplicate of this bug. ***
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"...
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.
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).
*** Bug 248651 has been marked as a duplicate of this bug. ***
Timeless fingers suspect code in nsLocalFileWin.cpp.  Cc'ing buddies.

/be
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.
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.
cc'ing brodie since he likes playing with nsLocalFileWin issues ;-)
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.
fixed by proxy of bug 252193. if the file is readonly, it won't be overwritten
and no bookmarks will be saved.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: bugs → dwitte
Status: REOPENED → NEW
Product: Browser → Seamonkey
*** Bug 244245 has been marked as a duplicate of this bug. ***
*** Bug 273576 has been marked as a duplicate of this bug. ***
Changing OS to all: 1 dupe from XP & 1 dupe from OS/2.
OS: Windows 2000 → All
QA Contact: claudius → seamonkey.bookmarks
Summary: read-only bookmarks.html causes creation of bookmarks-{n+1}.html → read-only/hidden bookmarks.html causes creation of bookmarks-{n+1}.html
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
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
Why patch one symptom of a basic flaw when you could fix the flaw itself,
described in bug 257288?
Depends on: 257288
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.
Status: NEW → ASSIGNED
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.
Summary: read-only/hidden bookmarks.html causes creation of bookmarks-{n+1}.html → read-only/hidden bookmarks.html (or bookmarks.html.moztmp) causes creation of bookmarks-{n+1}.html
See Bug 271883 for a patch to fix the problem for hidden files.
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
*** Bug 283243 has been marked as a duplicate of this bug. ***
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?
Hardware: PC → All
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...
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.
(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.
(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.
*** Bug 363416 has been marked as a duplicate of this bug. ***
-> default owner, helpwanted
Assignee: dwitte → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
With moving to Places this bug became obsolete, closing
Status: NEW → RESOLVED
Closed: 20 years ago12 years ago
Resolution: --- → INVALID
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.