Closed Bug 271883 Opened 20 years ago Closed 19 years ago

Multiple bookmark.html files being generated

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: dan.doyle, Assigned: vladimir+bm)

Details

(Keywords: fixed-aviary1.0.1, fixed1.7.6)

Attachments

(1 file)

remove FILE_HIDDEN from NSPR
1.44 KB, patch
mkaply
: review+
wtc
: superreview+
asa
: approval-aviary1.0.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0

I find that Firefox is creating muliple bookmark.html files (about 1,000) in the
Profiles subdirectory.  There have been over 1,000 at a time.  I clean them out
(because they take up a LOT of space) and they seem to just come right back. 
I have not noticed anything that is causeing this, but I am going to keep my
eyes open from now on.  I can provide a screen shot of the directory in question
at a point where I have cleaned it up and there are only about 25 bookmark.html
files (taken during this writing).

Reproducible: Didn't try
Steps to Reproduce:
1.seems to be spontanious - happens by iteself
2.
3.
Sorry:  need to add:

Operating system is OS/2 WARP 4 fixpack 16 (OS/2 4.50).

I am also using PREFBAR (2.3.1) and Flashblock 1.0RC2.

Looking at the Profile directory - it seems to be creating a copy of the
bookmark.html file evey 15 seconds while Firefox is up.  They are named
bookmarks-###.html where the ### ranges from 1 to lots.
Summary: Multiple bookmark.html files being generated → Multiple bookmark.html files being generated
Are you sure this isn't an extension that is set to back up your bookmarks? If
you go to about:config, what is the value of backups.number_of_prefs_copies ?
Is your bookmarks.html marked read only or hidden?
Assignee: vladimir → vladimir+bm
The backups.number_of_prefs_copies value is 1.

I only have Prefbar 2.3.1 and Flashblock 1.0RC2 installed as extensions.

The attributes for the bookmark.html file is:  " - - - a ".

I have re-booted a number of times since first reported and the problem is still
occurring (ie: not fixed by a reboot) - it continued on each reboot. 
I get this only occasionaly.
Last night, between 0:05 and 1:07, 215 bookmark files were created. Now, I'm
running firefox again (after reboot), no new files seem to be greated as of yet.
Extentions I have:
Flashblock 10.RC3
Disable Targets For Downloads 0.8
OpenDownload 0.2.1

While I'm running firefox now, the original bookmarks.html is marked hidden (the
others aren't). I can't remember setting this myself.

I do remember going through the bookmarks in the sidebar last night, visiting
pages I haven't visited for some time, removed some (about 5, not 215) dead
bookmarks. There was also one RSS feed open that didn't load (probably server
down). This one does load now.

Maybe one of the things above give a lead? Dan, could you for instance check
whether you have any live bookmarks that don't work?
I am not using RSS and the bokmark file is not hidden.

I do have a bunch of bookmarks in the file that are dead, but that was also the
case in previous verions of Firefox (I installed just about every one at one
time or another), and the problem did not happen prior to this verision.  There
were 245 copies of the file just before I made this update.
The bookmarks.html was hidden, also after closing firefox. I removed the hidden
bit, see what happens.

On another eCS installation, I didn't have multiple bookmarks.html, but a few
cookies.txt... Could that be related somehow?
Hi,

I have the same sympton here: hundred of bookmark copies are generated while
firefox is up.

Uwe
I am also experiencing the same problem of multiple bookmarks files being generated.  However my 
system is a Power Mac G4/400 running OS X 10.3.5; Firefox version is 1.0.  The multiple bookmarks 
files are of the form "bookmarks-xx.html" where xx starts at 1 and increments by 1 for each new file 
created.    Another file is generated every time Firefox is quit.  When I first discovered the problem 
there were 50+ additional files at 200 KB each.  Twice I have removed Firefox and its component files 
and reinstalled but the problem still persists.  File permissions appear to be OK.  This bug was also 
discussed on the mozillaZine Firefox support forum by wefunk on November 7, 2004:

<http://forums.mozillazine.org/viewtopic.php?t=157086&highlight=multiple+bookmark>

The thread contains a screenshot of the files in question.
Has this issue been addressed at all?  this is bad on my machine, it's a clean
install of W2K and default install of ff 1.0.    At one point I had 11,000
copies of bookmarks.html.  I've removed ff completely and redownloaded and
reinstalled.  No help.  Also getting the same behavior with the cookies file but
not as often/many.  I went through the dir structure all the way to C: and gave
everyone the full control permission, no help.  I see the file is writable
because new bookmarks show up in it, although the add bookmark dialog won't go
away like it's supposed to, I have cancel or "X" it out.  I also had the problem
with the 2 second hang every 15 seconds, but after the reinstall this no longer
an issue unless I leave the browser oipen for days, it starts doing it again. 
Could this bug be raised to critical?
On December 8, 2004 a new "refreshed" Firefox 1.0 was released for OS/2 users. 
I have installed this release going from: 
   Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041109 Firefox/1.0
to:
   Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5) Gecko/20041207 Firefox/1.0

The problem persists with this version of Firefox. I have deleted over 2,200
copies of the bookmarks-###.html files in the last few days - each is about
300K.  At one point all free space on my hard drive was consumed by these files.

I have gotten a number of e-mails from other users with this problem on
different platforms (UNIX, Win 2K) and I would like to raise the Severity of
this bug to "major" as a result.
Severity: normal → major
I am experiencing the same issue as well. So far up to 3000 bookmark files. As 
an added problem, since this has started occuring any new bookmarks added to 
the list are not saved to the file. I am currently just keeping new bookmarks 
in a flat text file until this gets fixed. I do not know if this has anything 
to do with the number of bookmarks because my bookmark file is at least 300kb. 
I also checked the permissions on the file because I just copied it into the 
bookmark.html into the profile directory, but the readonly bit was not marked. 
Not being able to add new bookmarks is a big issue, I am sure I could go in 
and edit the file by hand but thats too cumbersome.

Operating System: WinXP SP2
Extentions: ForecastFox 0.5.8
Vlad contacted me by email and we came up with a fix for my machine.  I had 
rebuilt the box with new HDD, when I restored my bookmarks, cookies and pref 
from the CD where I had parked them they showed up as read-only.  I fixed that, 
but apparently I had opened ff in the meantime and it made copies of the files 
and appended .moztemp to the names.  Unfortunately, it made exact copies, 
including the read-only bit set.  When it tried to write to the moztemp files 
they were read-only and that's when it started writing 1,000s of copies of 
those three files.  fixed that and it's all fixed, including the 2 sec of 100% 
CPU every 15 seconds.  so, look in your profile dir for files with moztemp, if 
they exist make sure ff can write to them.
Changing OS to All given the last comments.

I searched through some (OS/2) code yesterday looking for instances where
Firefox tries to change the file permissions with one of the various
possibilities the APIs or the C-Libraries give. I didn't really find one that
applies. Is it possible that all the reports have external causes like Tom's case?
OS: OS/2 → All
I think I have a suspect.

I re-installed Firefox 1.0 (Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.5)
Gecko/20041207 Firefox/1.0) with a clean install.  Only additions were the
plugins for Java (1.1, 1.2, and 1.3) and WarpVision (latest build).  This was
run for about 1 week with no problems with the bookmarks file.

Recently added Prefbar V3.0.0 extension.  Next thing you know the problem is
back and I have oodles of bookmarks and no space left on the partition!

I then disabled the extension for Prefbar (Tools > Extensions > Prefbar  > 
Disable), and I haven't had multiple bookmark files yet.  Prefbar seems to be 
suspect here (well, duh).  

I am going to enable and disable Prefbar at various stages to confim that it is
causing the problem and I will upated this bug at a later date.
Oh, this makes me realize that I never posted this here, only in the .os2
newsgroup. Mike Kaply found some code at
http://lxr.mozilla.org/seamonkey/source/nsprpub/pr/src/md/os2/os2io.c#184
that might cause a hidden attribute for files on OS/2. That code assumes
(wrongly in my view) that a unix-like mode of 002 means hidden on OS/2.

I made a test build of NSPR4.DLL for Firefox 1.0 (and Thunderbird 1.0) without
that code which is available from <http://weilbacher.org/temp/nspr4-test.zip>. I
haven't heard any more problem reports from the people who have downloaded it,
so it might work as a fix on OS/2.
This patch changes the function _PR_MD_OPEN so that the Unix-like mode
parameter is ignored, the way it is done in the respective functions on
Windows. This makes sense as the currently used code assumes a wrong relation
of mode to hidden.

I couldn't track down where in Firefox this actually gets called with mode=2
but from the reports I have gotten this has fixed the duplicate bookmarks
problem on OS/2. (After some short tests I thing that it does not cause new
problems with the suite, either.)
Attachment #172397 - Flags: superreview?(wtchang)
Attachment #172397 - Flags: review?(mkaply)
Comment on attachment 172397 [details] [diff] [review]
remove FILE_HIDDEN from NSPR

r=mkaply.

I wonder if all the other platform problems are due to readonly bookmarks
files?
Attachment #172397 - Flags: review?(mkaply) → review+
In the case of Mac OSX (10.3.5) I think it may well be a permissions problem.  Both bookmarks.html and 
bookmarks.bak have the following characteristics:

  Owner: me (501)
  Group: admin (80)
  World

  Permissions: -rw-r--r--
  CHMOD: 0644

If I change the Group permissions from r-- to rw- (CHMOD 0664), launch Firefox and quit, the 
application will write updated bookmarks files without creating a duplicate bookmarks.html file.  
However, it also changes the Group permissions back to r--.  The next time Firefox is run and quit, a 
duplicate bookmarks-x.html file is created.  I've tried this a half a dozen times or so with the same 
results.  Owner and World permissions are not affected.


I seem to have stopped the problem, but I'm not entierly sure what did it.  As
noted, I performed a clean install of Firefiox 1.0 (Mozilla/5.0 (OS/2; U; Warp
4.5; en-US; rv:1.7.5) Gecko/20041207 Firefox/1.0).  This ran for a couple of
days with no problems so I proceeded to the next step.
I then installed Prefbar 3.0.0, and then I started to get duplicate bookmarks -
not a lot or as frequent, but they were there.  I went into Tools>Extensions and
selected the Prefbar item and right-clicked and pressed "Disable".  From that
point on I get no more duplicate bookmark files.
A couple of days ago, as a test, I reactivated Prefbar and I have not had any
problems so far.  I have also installed Flashblock 1.2.8 and Adblock v.5 d2 *
nightly 39 - so far there have been no problems.
Also - for the record - the attributes on the bookmarks.html file are: ---a
I am going to run with the 3 add-ins for the time beeing to see whether any
problems result, but so-far, so-good!
Comment on attachment 172397 [details] [diff] [review]
remove FILE_HIDDEN from NSPR

sr=wtc.

By the way, you only need to implement the
"mode" argument in _PR_MD_OPEN_FILE.  On
OS/2, you define _PR_MD_OPEN_FILE to be
the same as _PR_MD_OPEN.  If you ever need
to implement Unix file mode, define
_PR_MD_OPEN_FILE as a different function
and implement "mode" there.
Attachment #172397 - Flags: superreview?(wtchang) → superreview+
Comment on attachment 172397 [details] [diff] [review]
remove FILE_HIDDEN from NSPR

Great, thanks for the hint, wtchang. Can you or someone else check this in,
please?

I also ask for 1.0.1 approval because of the low risk of this change.
Attachment #172397 - Flags: approval-aviary1.0.1?
I can check this in to the client branch, but wtc has to do NSPR trunk.
Comment on attachment 172397 [details] [diff] [review]
remove FILE_HIDDEN from NSPR

I checked in this patch on the NSPR trunk (NSPR 4.6).
Comment on attachment 172397 [details] [diff] [review]
remove FILE_HIDDEN from NSPR

a=asa for 1.0.1 checkin.
Attachment #172397 - Flags: approval-aviary1.0.1? → approval-aviary1.0.1+
Please see Bug 157152 for other cases of multiplication.
Vlad, if you're going to check this in for 1.0.1 it's got to be now.
Changing back to OS/2; comment 12 should probably be a separate bug.
OS: All → OS/2
As an OS/2 only bug, this is fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This landed on the aviary 1.0.1 branch, so marking fixed-aviary1.0.1.

Should this also go on the MOZILLA_1_7_BRANCH?
already done
Keywords: fixed1.7.6
I can't say that this is resolved (completely).  I have discovered another
situation where this is now occurring.

I am unable to automatically close the "downloads" window in OS/2 for some
reason so I have to close it manually.  If I leace the download window open, but
I close the primary Firefox window I start getting multiple bookmarks written. 
I was watching it do it just a few minutes ago.  It may have someting to do with
the secondary window being open.  

I have also noticed that the "hidden" attribute of the bookmarks.html file and
the bookmarks.bak file have been set.  I don't know who (or what) is doing that,
but the last I looked, the attribure was NOT set.  Anyone know why the attribute
is being changed? 



Dan, do I understand correctly that you are using Firefox 1.0.1 for OS/2 now and
that after removing the hidden attribute of the bookmarks files it appears again?
As of 3-09-2005 this bug is still present in Firefox 1.0.1, ver 1.7.6, build
2-28-05.  A clean install was done after firefox 1.0 was completely removed. 
Disk activity every 15 seconds and the many bookmark files in the profile
directory were observed.  Removing them and changing the hidden attribute on
bookmark.html resolves the issue.
After some reports here and in the newsgroup I am reopening this, although the
number of such reports is much less now than before the fix.

Also because I just found 
http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileOS2.cpp#568
which seems to call PR_Open for all normal files with the PR_RDONLY attribute. I
don't understand why that is and if the bookmarks file creation goes through
this call but I find it strange. Shouldn't that be changed to PR_RDWR?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Wait, sorry. That was rubbish. PR_RDONLY is not reflected in the file system
attributes, and as nothing is written to the file at that point this is correct.
I can concur that this is happening on Mac OS X 10.4 Tiger (and 10.4.1) with
permissions set correctly on bookmarks.html. This is quite annoying. Never would
have noticed if it hadn't been for Spotlight :-)

Drew
User Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050819 Firefox/1.0+

Happening to me on Mac OS X 10.4.2 across multiple Macs.
my system:
AMD K6/333
192MB RAM
win98se - nearly new install
mozilla with flashblock extention

Mozilla is using 36% of total CPU resources over a long term.
Its CPU graph is like a square wave.
100% CPUsage for 11 seconds
20% CPUsage for 15 seconds
repeating steadily, even if it is only open to 1 about:blank window [to
eliminate flash-induced loads from some poorly designed webpages]

I was running 1.7.11, then reverted to 1.7.7 and the problem remains.

update:
I manually removed the files uninstall left behind i.e. cache, plugins etc.
On reinstall, the cycling CPU overload was gone.

I then loaded my precious 86kb bookmark file stored in another subditrectory. 
Thus caused the huge CPUsage cycles again.  And I just found 2500+ numbered
back-up copies of this bookmark file.  Mozilla is creating them at the rate of
2-4/minute when it is running.

Some minutes ago, I deleted the 2500 redundant copies of the 86kb bookmark file.
 There are 121 new copies of it already, in the intervening 30 minutes.

I try to reload the 2kb default bookmark file to test more but am having trouble
doing that with the bookmark manager.  It would not release the 86kb file and
load the 2kb file.  I had to close mozilla and rename files to get it done.

I finally closed mozilla and renamed the target bookmark file so mozilla
wouldn't reload it on re-start.  I was then able to load the default 2kb file,
no problems so I copied the big bookmark file to the same operating folder. 
again no problems so far.

I noticed a file called bookmarks.html.moztmp in the alternate subdirectory
where all the copies were being created.  Could that be related?  Could this be
some residual file that was causing the repeated replication?

I copied that bookmarks.html.moztmp into the mozilla\profile\default\xxxxx.slt
folder where the bookmark file is normally stored.  Sure enough, on next
restart, mozilla started replicating the bookmark file again and causing 100%
CPU loads in doing so.

Now that I identified bookmarks.html.moztmp as the likely culprit, I did google
search and found that it was related to several bug reports including:  157152,
260553 and 271883

My theory is that bookmarks.html.moztmp is meant to be just a tempoary file that
was left behind on a crash and on restart, mozilla didn't clean it up.  As long
as it is present, it seems mozilla will run wild creating countless duplicates
of the same bookmark file.  I thought 2500 was bad.  seems another user reported
having 11000 copies of his bookmarks.  For whatever difference, neither
bookmarks.html.moztmp or bookmarks.html was marked hidden or read only on my
system like others have reported on theirs.

Now that I have manually deleted bookmarks.html.moztmp, mozilla is using less
than 7% or CPU resources.  I can live with that.
*** Bug 311829 has been marked as a duplicate of this bug. ***
(In reply to comment #38 #37)



For MACINTOSH user (especial 10.4 Tiger user), see:


https://bugzilla.mozilla.org/show_bug.cgi?id=294584


It's a spotlight index problem.
OK, marking this one fixed, as I haven't seen any OS/2 reports recently.

The problems on Mac seem to be bug 294584 and similar WinXX bugs always got
duped to bug 157152, so users of those OSes should comment in those bugs rather
then here.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: