Closed Bug 283243 Opened 19 years ago Closed 19 years ago

Bookmarks manager is hideous in multiple ways, including creation of multiple copies of the BM file, and no attempts seem to have been made to fix it!! Persistent since v. 1.7.1. If unchecked, this can result in hundreds or thousands of copies of the...

Categories

(SeaMonkey :: Bookmarks & History, defect)

Product:
SeaMonkey
Component:
Bookmarks & History
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 157152

People

(Reporter: 0py4obm02, Assigned: p_ch)

References

Details

(Keywords: dataloss) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

I have my bookmarks set to a non-default location and filename [bookmark.htm]. 
Through moz v. 1.6, a problem persisted of not re-writing/updating the file when
changes were made, and those changes were lost until I realized this and began
manually exporting the file after editing.  Now, since a v. 1.7.x [verified as x
>=5], which apparently tried to fix this failure of the bookmarks file to
update, more than one copy a minute of the file is written, each with a
sequential integer appended to the filename.  If unnoticed unchecked, this can
result in hundreds or thousands of copies of the bookmarks file!!

Reproducible: Always

Steps to Reproduce:
1.open mozilla 
1.b.(?)bookmarks file in non-default location, may or may not matter(?)
2.leave it open
3.numerous duplicate files are created
4.NOTE neither the directory nor the file is read-only
5.NOTE this is nothing special; it happens on all three PC's on which I use
mozilla, EXACTLY the same.  
Actual Results:  
Incredibly numerous additional copies of the file are written into the assigned
directory, each with a sequential integer appended to the filename.  If
unnoticed unchecked, this can result in hundreds or thousands of copies of the
bookmarks file!!

Expected Results:  
Rewrite/update the same bookmarks file.  

***PLEASE*** do something with this hideous bookmarks 'manager', which is
getting WORSE, not better!!!!!!
Your lizard is too old to report bugs against. Your bug may already have
been fixed.

You may find that if 'new work' is required to fix your problem, then it
will not be done on the Mozilla Suite only Firefox.
(In reply to comment #1)
> Your lizard is too old to report bugs against. Your bug may already have
> been fixed.
> 
> You may find that if 'new work' is required to fix your problem, then it
> will not be done on the Mozilla Suite only Firefox.

NOSIR, I am reporting that this persists to v. 1.8/a6. Sorry if that was not
entirely clear, but this is NOT AN OLD VERSION.  Also, NO, it is NOT fixed!

This also goes back to v. 1.7.1, making it LONG-STANDING and PERSISTENT.  This
needs to be fixed *in the mozilla suite*, firefox still has numerous
inconsistency problems that prevent many of us from using it.  Restricting a
'fix' to firefox would be an idiotic move.  Beyond which, I don't believe this
happens in firefox.  

This is similar to 251027, and potentially could be considered a duplicate
thereof.  However, I reported it as a 'new' bug because of the ludicrously long
time and number of versions over which it has persisted.  

(In reply to comment #1)
> Your lizard is too old to report bugs against. Your bug may already have
> been fixed.
> []

Oh, sorry, I see why you said that.  I *reported* using 1.6 [because it does not
exhibit this behavior].  The behavior occurs every step I've checked from 1.7.1
to 1.8/a6.  
Reporter please read bug 157152 to see if your problem is caused by hidden or
readonly and dupe this if it is.
(In reply to comment #4)
> Reporter please read bug 157152 to see if your problem is caused by hidden or
> readonly and dupe this if it is.

I did, along with every other bug I could find that appears even marginally
related.  Seemingly, you should have noticed this in my report:

"4.NOTE neither the directory nor the file is read-only"

Neither are they hidden.  Apart from those specifics, though, the behavior does
seem similar.  However, since this has nothing to do with RO/H, this is NOT a
dupe.
Summary: Bookmarks manager is hideous in multiple ways, and no attempts seem to have been made to fix it!! Now, since a v. 1.7.x which apparently tried to fix the failure of the bookmarks file to update, more than one copy a minute of the file is written each wit… → Bookmarks manager is hideous in multiple ways, including creation of multiple copies of the BM file, and no attempts seem to have been made to fix it!! Persistent since v. 1.7.1. If unchecked this can result in hundreds or thousands of copies of the boo…
Is your non-default location on removable media or network?
(In reply to comment #6)
> Is your non-default location on removable media or network?

Nope, same drive and partition as that on which moz is installed.  And, again,
neither the file nor any parent directory is read-only or hidden.  

Is your system configured with more than 1 user login?
(In reply to comment #8)
> Is your system configured with more than 1 user login?

Yes it is, though the account in which I experienced this is an admin account.  

Also, FWIW, I have only one moz profile set up. 

I don't know if 2000 is like XP, but I suspect it is. If you back up files, then
restore them as the wrong user, the intended user won't have write permission on
the restored files, even though he can find and open them. Have you done
anything that may have placed your bookmarks file or profile directory in a
location with permission only as the wrong user?
(In reply to comment #10)
> I don't know if 2000 is like XP, but I suspect it is. If you back up files, then
> restore them as the wrong user, the intended user won't have write permission on
> the restored files, even though he can find and open them. Have you done
> anything that may have placed your bookmarks file or profile directory in a
> location with permission only as the wrong user?

No, this is not a permissions issue in any way.  Win2k is different from XP in
many ways, but the permissions to which you refer I believe are specific to
NTFS, aspects of which I abhor [including permissions behavior].  Although Win2k
can apply NTFS, my disks relevant to this report all are FAT32, in which that
type of permissions issue [and many others] are irrelevant.
Version: unspecified → Trunk
I have been experiencing the same problem with Mac OS X 10.3.8 since the problem
with disappearing bookmarks was fixed. My bookmark file is not locked, (I did
have a locked version about 6 months ago - long since deleted.) and it is in the
default location.

Just recently I started to get duplicates of my prefs.js file and my forms  file.

I am using Mozilla 1.8b2 build 2005030510

(In reply to comment #0)
There is a
[url=http://forums.mozillazine.org/viewtopic.php?p=1423244#1423244]report[/url]
on the Fx Support Forum that this can happen if file bookmarks.html.moztmp is
ReadOnly.
Sorry about the formatting of that last comment.  Based on the strength and
clarity of the report from the Support Forum, this bug appears to be essentially
confirmed.  However, it's confirmed for Fx 1.0.3, not Trunk.
(In reply to comment #14)
> Sorry about the formatting of that last comment.  Based on the strength and
> clarity of the report from the Support Forum, this bug appears to be essentially
> confirmed.  However, it's confirmed for Fx 1.0.3, not Trunk.

Please note in the original description this has *nothing* to do with *read only*:

4.NOTE neither the directory nor the file is read-only

I would say yes it should be trunk, as I reported this in mozillas [not Fx].  I
sure wish this bookmarks garbage would get some actual attention!  Maybe it
would help if you all would *vote* for this bug(?).
Keywords: dataloss
(In reply to comment #13)
> (In reply to comment #0)
> There is a
> [url=http://forums.mozillazine.org/viewtopic.php?p=1423244#1423244]report[/url]
> on the Fx Support Forum that this can happen if file bookmarks.html.moztmp is
> ReadOnly.


Thanks for that link; in a link posted within that, I found what *really* may
have caused this problem, though I'll not be able to verify that for a while yet.  

http://forums.mozillazine.org/viewtopic.php?t=255641

The critical issue there is:

"You need to check bookmarks.html, bookmarks.bak, and bookmarks.html.moztmp to
see if they are ReadOnly. In this case the problem was caused by
bookmarks.html.moztmp being set ReadOnly. You just have to set it not ReadOnly
to solve the problem."

I'd never seen anything previously about the .moztmp files, nor had I ever
noticed the files, but sure enough that was present and read-only, and may have
been what precipitated the problem for me also.  Thanks again.

*** Bug 251027 has been marked as a duplicate of this bug. ***
see comment 16

*** This bug has been marked as a duplicate of 157152 ***
URL: na [bookmarks file]
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
(In reply to comment #17)
> ***  has been marked as a duplicate of this bug. ***

While I am glad to see these issues finally seemingly getting some attention, I
believe you have this duplication sort of backwards.  Bug 251027 is considerably
*older* than this one, though admittedly I crafted this one to supercede 251027,
as the details are more generalized.  I certainly hope this annoying behavior
gets rectified ASAP.  Thanks.  
The original summary for this bug was longer than 255 characters, and so it was truncated when Bugzilla was upgraded. The original summary was:

Bookmarks manager is hideous in multiple ways, including creation of multiple copies of the BM file, and no attempts seem to have been made to fix it!!  Persistent since v. 1.7.1.  If unchecked, this can result in hundreds or thousands of copies of the bookmarks file!!
You need to log in before you can comment on or make changes to this bug.