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

RESOLVED INVALID

Status

SeaMonkey
Bookmarks & History
RESOLVED INVALID
15 years ago
5 years ago

People

(Reporter: rcummins, Unassigned)

Tracking

({helpwanted})

Trunk
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [2012 Fall Equinox], URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
*** Bug 189651 has been marked as a duplicate of this bug. ***

Comment 2

15 years ago
*** Bug 193141 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 3

15 years ago
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

15 years ago
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

15 years ago
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

13 years ago
*** Bug 248651 has been marked as a duplicate of this bug. ***
Timeless fingers suspect code in nsLocalFileWin.cpp.  Cc'ing buddies.

/be

Comment 8

13 years ago
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

13 years ago
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

13 years ago
cc'ing brodie since he likes playing with nsLocalFileWin issues ;-)

Comment 11

13 years ago
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

13 years ago
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
Last Resolved: 13 years ago
Resolution: --- → FIXED
(Reporter)

Comment 13

13 years ago
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 → ---

Updated

13 years ago
Assignee: bugs → dwitte
Status: REOPENED → NEW
Product: Browser → Seamonkey

Comment 14

13 years ago
*** Bug 244245 has been marked as a duplicate of this bug. ***

Comment 15

13 years ago
*** Bug 273576 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
Changing OS to all: 1 dupe from XP & 1 dupe from OS/2.
OS: Windows 2000 → All

Updated

13 years ago
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

Comment 17

13 years ago
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

Comment 19

13 years ago
Why patch one symptom of a basic flaw when you could fix the flaw itself,
described in bug 257288?
Depends on: 257288

Comment 20

13 years ago
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

Comment 21

13 years ago
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

Comment 22

13 years ago
See Bug 271883 for a patch to fix the problem for hidden files.

Comment 23

13 years ago
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

Updated

12 years ago

Comment 24

12 years ago
*** Bug 283243 has been marked as a duplicate of this bug. ***

Comment 25

12 years ago
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

Comment 26

12 years ago
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

12 years ago
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

12 years ago
(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

12 years ago
(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

11 years ago
*** Bug 363416 has been marked as a duplicate of this bug. ***
Depends on: 368317

Comment 31

10 years ago
-> default owner, helpwanted
Assignee: dwitte → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted

Comment 32

5 years ago
With moving to Places this bug became obsolete, closing
Status: NEW → RESOLVED
Last Resolved: 13 years ago5 years ago
Resolution: --- → INVALID
Whiteboard: [2012 Fall Equinox]
You need to log in before you can comment on or make changes to this bug.