All users were logged out of Bugzilla on October 13th, 2018

Downloads.rdf keeps on growing

VERIFIED FIXED

Status

VERIFIED FIXED
17 years ago
14 years ago

People

(Reporter: fredbezies, Assigned: bugzilla)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt3 rtm] [verified on trunk])

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0+)
Gecko/20020507
BuildID:    2002050705

I download about 20 or 30 files a day. My download.rdf files keeps on growing,
even after I clear downloaded file list.

This behaviour happens since 2 or 3 days.

Reproducible: Always
Steps to Reproduce:
1.Download some files
2.clear downloaded files list


Actual Results:  download.rdf keeps on growing

Expected Results:  download.rdf should be more little in size as file list is
cleared.

Comment 1

17 years ago
Downloads.rdf can be viewed in a text editor. It stores a reference to all saved
files. It never clears. 

Is anyone seeing this on a platform/OS other than Windows?
Keywords: mozilla1.0.1, nsbeta1
Summary: Download.rdf keeps on growing. → Downloads.rdf keeps on growing.

Comment 2

17 years ago
nsbeta1- per nav triage team
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha

Comment 3

17 years ago
pulling back for retriage. 

blaker: how much work is it to remove resources that are no longer on the 
active (UI-visible) list of downloads?
Keywords: nsbeta1- → nsbeta1
Target Milestone: mozilla1.2alpha → ---

Updated

17 years ago
Keywords: mozilla1.1

Comment 4

17 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha

Comment 5

17 years ago
Downloads.rdf it's re-written 3 times while saving a file!!
This stuff slows down (freezes) the whole browser!!!

Comment 6

17 years ago
This problem affects Mozilla 1.0.0 too.

Comment 7

17 years ago
I have a patch that removes the resource as well when it is removed from the 
Seq in RemoveDownload.

Removing nsbeta1- for re-re-triage. I don't see how it is preferable to just
leave dead content on disk forever.
Keywords: nsbeta1- → nsbeta1
Target Milestone: mozilla1.2alpha → ---

Comment 8

17 years ago
Created attachment 87889 [details] [diff] [review]
RDF flailings; unassert resource arcs when removing from Seq

I have a suspicion that there might be a simpler way (e.g., an existing utility
method) to do this, but this does the job.

(It doesn't address cleaning up existing downloads.rdf, and I'm not sure 
what (if) to do about that).

Comment 9

17 years ago
adding nsbeta1- per nav triage team.  Let's fix it for the next release.
Keywords: nsbeta1 → nsbeta1-

Comment 10

17 years ago
I don't think you appreciate the risk and consequences of _not_ removing 
stale resource entries from downloads.rdf.

Consider a user who has ever downloaded 1000 items with the download manager
ever in the lifetime of their use of the browser. That is not what a typical
user will do, but it is not out of the realm of possible use. (Note that this
bug report begins with the assertion that the user downloads 20 to 30 files 
per day, and at that rate, this is less than 2 months of usage).

Now, even when the user removes the items from the visible UI, they are not
removed from the downloads.rdf and these dead resources will continue to be
maintained by the RDF datasource (i.e., read from and written to disk file and 
manipulated in memory).

With 1000 dead entries in downloads.rdf, on my 500MHz/128MB/win2k system, it 
now takes 3 seconds longer to open the download manager with noticeable lockup 
of the UI, it takes over one second to delete an item (batching or no batching) 
and it consumes an additional 1.0 megabytes of RAM.

There is zero benefit to the end user, there is measurable cost for the end 
user, and there is an unknown amount of stability risk in _not_ removing stale 
entries. Fixing this in the next release is too late.
Keywords: nsbeta1- → nsbeta1
Comment on attachment 87889 [details] [diff] [review]
RDF flailings; unassert resource arcs when removing from Seq

sr=ben@netscape.com
Attachment #87889 - Flags: superreview+
(Assignee)

Comment 12

17 years ago
Comment on attachment 87889 [details] [diff] [review]
RDF flailings; unassert resource arcs when removing from Seq

r=blake
Attachment #87889 - Flags: review+

Comment 13

17 years ago
Nav triage team: nsbeta1+, adt3 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3 rtm]
(Assignee)

Comment 14

17 years ago
fixed on trunk.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
Comment on attachment 87889 [details] [diff] [review]
RDF flailings; unassert resource arcs when removing from Seq

a=asa (on behalf of drivers) for checkin to the 1.0.1 branch.
Attachment #87889 - Flags: approval+

Comment 16

17 years ago
please check this into the 1.0.1 branch and change the mozilla1.0.1+ keyword to
"fixed1.0.1" 
Keywords: mozilla1.0.1, mozilla1.1 → mozilla1.0.1+
(Assignee)

Comment 17

17 years ago
Fixed on branch.
Keywords: mozilla1.0.1+ → fixed1.0.1
vrfy'd fixed using trunk commercial builds (2002.06.20.0x) on linux rh7.2, win2k
and mac 10.1.5.

1. remove downloads.rdf for the profile being tested.
2. start browser, save a couple of .html files.
3. view downloads.rdf, observe that there are RDF:Description for each file.
4. go to download manager window and delete both file entries.
5. go back and view downloads.rdf again.

results (expected): RDF:Description for each file deleted has been removed.
Status: RESOLVED → VERIFIED
Summary: Downloads.rdf keeps on growing. → Downloads.rdf keeps on growing
Whiteboard: [adt3 rtm] → [adt3 rtm] [verified on trunk]
*** Bug 157491 has been marked as a duplicate of this bug. ***
i'll wait till bug 153480 is fixed on the branch (keep getting erratic crashes
because of it)...
vrfy'd fixed on the BRANCH using 2002.07.22 commercial branch builds on linux
rh7.2, win2k and mac 10.1.5. tested used steps in comment 18.
Keywords: fixed1.0.1 → verified1.0.1
*** Bug 161578 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
downloads.rdf is also growing if you do not use the download manager. I verified
this on Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.1) Gecko/20020827.

I wondered for a long time why downloads kept going slower and slower. I used
download manager only for (few) very large files, I never realized that each and
every download gets listed there (why?).

For some time I believed the slow speed was due to my large and fragmented HPFS
disks which were nearly full. But after upgrading to 27 GByte of LVD Ultra-SCSI
my disks should not be a problem any longer, but still downloads were slow.

Finally it took up to two seconds after launching a download that the Save As
dialog came up and after confirming of download location the machine spent up to
six seconds at 100 percent CPU load (on a Pentium-III 450 MHz with 256 MByte
RAM) which of course locked up the entire machine.

Today I suspected download manager and found several hundred files in there
(yes, this is achievable by normal people...). Marking one and deleting it took
two seconds at 100 percent CPU load, marking all of them and deleting them (I
miss a button to do that!) was something that I stopped by killing Mozilla after
20 minutes (!) at 100 percent CPU load.

So while the bug as described here initially may be fixed (items removed from
the UI actually disappear from downloads.rdf) I suggest added a size or number
of entries limitation into Edit | Preferences | Downloads. Furthermore I suggest
adding a "delete all entries" button and I suggest that only downloads done in
download manager be listed at all. Otherwise, all Mozillas out there will
eventually run out of power...
QA Contact: sairuh → petersen

Comment 24

16 years ago
Yes, you raise a valid concern. There is a bug open which proposes three 
solutions to this problem, including (essentially) two of the suggestions
you've made here. See bug 161783, which is scheduled to be fixed.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.