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)
SeaMonkey
Bookmarks & History
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: rcummins, Unassigned)
References
()
Details
(Keywords: helpwanted, Whiteboard: [2012 Fall Equinox])
Attachments
(1 file)
743 bytes,
patch
|
Details | Diff | Splinter Review |
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•21 years ago
|
||
*** Bug 189651 has been marked as a duplicate of this bug. ***
Comment 2•21 years ago
|
||
*** 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"...
Comment 4•21 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•21 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).
*** Bug 248651 has been marked as a duplicate of this bug. ***
Comment 7•20 years ago
|
||
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.
Comment 10•20 years ago
|
||
cc'ing brodie since he likes playing with nsLocalFileWin issues ;-)
Comment 11•20 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•20 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
Closed: 20 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 13•20 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•20 years ago
|
Product: Browser → Seamonkey
Comment 14•20 years ago
|
||
*** Bug 244245 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
*** Bug 273576 has been marked as a duplicate of this bug. ***
Comment 16•20 years ago
|
||
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
Comment 17•20 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
Comment 18•20 years ago
|
||
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•20 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•20 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•19 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•19 years ago
|
||
See Bug 271883 for a patch to fix the problem for hidden files.
Comment 23•19 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
Comment 24•19 years ago
|
||
*** Bug 283243 has been marked as a duplicate of this bug. ***
Comment 25•19 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•19 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•19 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•19 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•19 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•18 years ago
|
||
*** Bug 363416 has been marked as a duplicate of this bug. ***
Comment 31•17 years ago
|
||
-> default owner, helpwanted
Comment 32•12 years ago
|
||
With moving to Places this bug became obsolete, closing
Status: NEW → RESOLVED
Closed: 20 years ago → 12 years ago
Resolution: --- → INVALID
Whiteboard: [2012 Fall Equinox]
You need to log in
before you can comment on or make changes to this bug.
Description
•