Closed Bug 200498 Opened 21 years ago Closed 21 years ago

Multiple copies of my bookmarks file are showing up in TEMP / bookmark changes are lost / cannot modify or delete

Categories

(SeaMonkey :: Bookmarks & History, defect, P1)

Product:
SeaMonkey
Component:
Bookmarks & History
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: agracebush, Assigned: janv)

References

Details

(Keywords: dataloss, regression, Whiteboard: [adt2])

Attachments

(1 file)

patch
3.50 KB, patch
janv
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
Steps to reproduce:
Install Mozilla 4/3 nightly
Check TEMP directory (see bug 197847)
notice bookmarks.html and bookmarks-1.html files
Install commercial 4/3 nightly (testing GRE) 
check TEMP again
now  bookmarks-2 and bookmarks-3 files show up

did more installs and get 2 copies of the bookmarks file each time

adding ssu in case he is aware of bookmark changes during installation
Confirmed in build 2003040305 on Mac OS X 10.2.4, so changing to all/all.

I saw several bookmarks.html files in my /tmp directory. I cleared them, and
restart Mozilla. Nothing appeared in that directory. When I closed Mozilla again
( I didn't open the bookmark-manager), I saw a bookmarks.html and a
bookmarks-1.html file in /tmp . Both were exactly identical to my real
bookmarks.html file, I checked with diff. When I restarted again, a
bookmarks-2.html and a bookmarks-3.html appeared. And so on.

This must be related to the new bookmark-code that has been checked in. The
files are written during shutdown.
OS: Windows 2000 → All
Hardware: PC → All
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030403
A hour ago I deleted 30 bookmarks.html, @1385 kb each. Now I have again 10
bookmarks.html, but the youngest has only 1382 kb, though I didn´t change
anything. My volumecounter shows 30 mins online-time, but 5 minutes ago DUN came
up and did an auto-reconnect. I don´t know, if I´ve been offline or not.
Are these bookmarks.html written when going on- and offline?
I see this too, and I think I know why they are being created.  I have been
adding bookmarks to my Personal toolbar, but couldn't figure out why it wasn't
staying there after a restart of the browser.  The Personal tool bar kept
reverting to the previous state.

I did a grep in the bookmarks*.html files (I have 1-27) in the %temp% dir for
the bookmarks that I know I saved and sure enough they were there, but not in my
profiles dir's bookmark file.

Looks like someone tweaked something related to the bookmarks path or the
bookmarks code itself.
reassigning to jan for now, per ssptizer's recommendation
Assignee: ben → varga
Severity: normal → critical
Keywords: nsbeta1
Priority: -- → P1
This can be related to recent nsIFile changes in bookmarks service.
Status: NEW → ASSIGNED
I think the error must be at 

http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#4901

or the lines immediately preceeding it. Works for me on Win2k and linux. Can
somebody who is experiencing this run a debug build and see if there are any
debug messages at shutdown that might present a clue?
I have a patch for this.
I'm on Mac OS X, but I don't have a debug-build ready to test (and I'm leaving
for Paris this evening anyway).

I know that the bookmark file is created first in /tmp and copied to the real
location later. And why 2 (identical) bookmark files ? I'm thinking that we
actually write the bookmark file twice, but nobody ever noticed. Maybe that part
of the shutdown code is executed twice.
*** Bug 200401 has been marked as a duplicate of this bug. ***
Attached patch patch — — Splinter Review 
first important thing here is the change from CopyTo() to MoveTo()
CopyTo() can fail if the destination file already exists.
There is another thing I changed. The temp file should be created in profile
directory not in the temp dir (as it was before).
Attachment #119446 - Flags: superreview?(jaggernaut)
Attachment #119446 - Flags: review?(bsmedberg)
*** Bug 200669 has been marked as a duplicate of this bug. ***
Comment on attachment 119446 [details] [diff] [review]
patch

>+    rv = tempFile->CreateUnique(nsIFile::NORMAL_FILE_TYPE, /*octal*/ 0664);

I think that this should be 0600, see bug 59557 for discussion.

>-    rv = tempFile->CopyToFollowingLinks(bookmarkParentDir, bookmarkLeafName);
[snip]
>+        rv = tempFile->MoveTo(bookmarkParentDir, bookmarkLeafName);

Part of the fix for bug 191783 was to allow symlinked bookmarks files. This fix
breaks symlinks, but I don't know the correct solution.

so r=bsmedberg for this short-term fix, and let's look at how to make symlinks
work.
>I think that this should be 0600, see bug 59557 for discussion.

no problem, I'll change that.

>Part of the fix for bug 191783 was to allow symlinked bookmarks files. This fix
>breaks symlinks, but I don't know the correct solution.

actually, it never worked on MacOS X, so it can't break something that is
already broken

>
>so r=bsmedberg for this short-term fix, and let's look at how to make symlinks
>work.

Well, I don't consider this as a short-term fix. I think it's the right thing to
do with the current nsIFile API.

We simply can't use CopyToFollowingLinks() because that may fail if the
destination file already exists (it's explicitely documented in nsIFile.idl)

anyway, thanks for review

*** Bug 200674 has been marked as a duplicate of this bug. ***
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Keywords: regression
*** Bug 200778 has been marked as a duplicate of this bug. ***
Tweaking summary for better Bugzilla queries.
Summary: Multiple copies of my bookmarks file are showing up in TEMP → Multiple copies of my bookmarks file are showing up in TEMP / bookmark changes are lost / cannot modify or delete
*** Bug 200779 has been marked as a duplicate of this bug. ***
I guess that this bug is related to bug 199328 for Phoenix.
it's not related to bug 199328
*** Bug 200815 has been marked as a duplicate of this bug. ***
*** Bug 200867 has been marked as a duplicate of this bug. ***
*** Bug 200879 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
Keywords: dataloss
*** Bug 200979 has been marked as a duplicate of this bug. ***
Attachment #119446 - Flags: superreview?(jaggernaut) → superreview+
Attachment #119446 - Flags: review?(bsmedberg) → review+
checked in
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 201022 has been marked as a duplicate of this bug. ***
could bug 188401 be an early report of this or is that just out of window of
this regression?
Sounds like bug 188401 is just like what happened to me
Now I can save bookmarks again! Thanks to the people that have been working on
this :-) Anyone else that can verify? Build ID: 2003040708
WFM win32, XP-pro 2003040708
I am not seeing bookmark file copies today
*** Bug 201085 has been marked as a duplicate of this bug. ***
Build 2003040708, Win98 here. It works fine. Thanks :-)
WFM with 2003040708/win2k. marking verified based on that and previous comments.
Status: RESOLVED → VERIFIED
anyone noticed that bookmarks export has also regressed as well?
please file a separate bug for that


*** Bug 201154 has been marked as a duplicate of this bug. ***
*** Bug 201553 has been marked as a duplicate of this bug. ***
*** Bug 201687 has been marked as a duplicate of this bug. ***
*** Bug 202181 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
*** Bug 203954 has been marked as a duplicate of this bug. ***
> actually, it never worked on MacOS X, so it can't break something that is
> already broken

It worked fine on Unix.  And people keep breaking it just because they don't use it.

The nsIFile API allows you to check when a file is a link and to resolve it if
it's one.  Please do make use of those facilities.

Follow-up discussion in bug 198138 
Actually, scratch that.  Bug 198138 is mac-only.  I've filed bug 225055 for the
XP issue.
Product: Browser → Seamonkey
This should NOT be shown as fixed, a very similar problem persists in moz 1.8/a6
[though not specific to a temp/tmp directory]!  I filed a 'new' bug on that,
283243, which also relates to 251027.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: