Closed Bug 438289 Opened 17 years ago Closed 13 years ago

Downloads disappearing from download manager

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: alicebot, Unassigned)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 This has happened to me 3 times already - sometimes, finished downloads just disappear from the download history (even if they finished fine). These problems only seem to appear when using the "download selection" menu item from the FlashGot extension (I assume that once the downloads are mass-added, Firefox takes over, so this probably isn't a problem with FlashGot). I tried to reproduce it reliably, but it only seems to happen sometimes (even on identical file sets)... besides, you really have to remember that you downloaded something, which makes it a bit hard to spot (I often just "download and forget" and get back to my downloads only once in a while). I'm not sure if this happens only with flashgot - but it's easier to notice if one file of several related files is missing, instead of any random download. Reproducible: Couldn't Reproduce Steps to Reproduce: 1. Have FlashGot installed 2. Select a bunch of links for downloading 3. select "FlashGot selection" from the context menu 4. wait until the files are finished Actual Results: Some of the downloaded files are not present in the download manager (even if they are on disk) Expected Results: All downloaded files stay in the download manager until removed explicitly. This happens almost immediately, and all other downloads (older or newer) are intact.
In about:config, what's the value of |browser.download.manager.retention|? If it's 0, then this isn't a bug; additionally, if this does NOT happen in Safe Mode, it's likely to be a FlashGot bug.
The retention is set to 2. It's a bit hard for me to verify it in safe mode, because I haven't found a way to reliably reproduce it. I'll post a link to this bug to FlashGot's forums, maybe Giorgio can shed some light on this.
Investigating.
How long do you keep your browsing history? The download manager clears items when they expire from history.
My history is set to 365 days. This happened to downloads immediately (on the same day) I downloaded them - older downloads were still there (the downloads were removed from near the top of the list, older items were kept intact).
This is really starting to get weird - a lot of the downloaded files (for example, those I made the screenshot on https://bugzilla.mozilla.org/attachment.cgi?id=324419 ) are missing from the download list... I downloaded them yesterday (it's 10 minutes past midnight). It feels like I'm going nuts, because I really don't remember removing all those downloads manually from the history. Could FlashGot set some wrong dates on the files, so they expire prematurely? Where are the downloads stored, in a sqlite database? Should I try the SQLite Manager extension or something like that if I can spot something weird in the DB?
OK, I'm not sure if this is it, but the download start time of files added using FlashGot are "truncated" - FlashGot seems to add times in seconds, while microseconds are expected (http://developer.mozilla.org/en/docs/PRTime). For example, two files added shortly one after another have the following times: 1213139009944750 - added normally 1213139075 - added with FlashGot The end times for both files seem to be OK. Do files expire from the download history according to the start time, or end time (either way would be weird, the end time is correct, and some older downloads with a weird start time are still kept in the download manager).
Kim, I just noticed that as well and fixed it in FlashGot 1.0.3 (to be released tomorrow). Not sure if it's the origin of this report, but it may be plausible if, as you suggest, expire time is calculated since the beginning of the download.
Giorgio, thanks! I'll try it as soon as it's available. In the meantime, I found out that downloads probably expire according to the places database (moz_historyvisits.visit_date), and that downloads get added as visits (with the same date as their start date). Downloads that don't have a visit/places entry don't get expired. For some reason, some of the downloads added with FlashGot don't have an entry in places - I presume that they will be stuck in the history indefinitely (this actually explains why some of the downloads didn't disappear, even though their start time is 38 years in the past). Does FG have to explicitly add the downloaded files to places/visits, or is this done automatically? If it's done automatically, how come that some downloaded files don't have an entry in places, while still being in the download list? Should I file a new bug?
How does flashgot add downloads to the download manager? The download manager adds an entry to history any time it doesn't have a mimeinfo passed in (this is because it's only needed for open with downloads). And yeah, it expects a PRTime, which is Date.now() * 1000.
Shawn, FlashGot always sent a null mimeinfo to addDownload() and, in 1.0.3 which I'm releasing, uses Date.now() * 1000, per comment 8.
Then you should always get added to history, and now you won't expire so fast :)
Shawn, am I correct in my understanding that expiration of the download history is driven solely by places, and if some url doesn't have an entry in places.sqlite database, then it won't be expired from the download history? I'd like to close this bug (the issue with disappearing files is indeed fixed, I haven't missed any files since upgrading FlashGot), and I consider opening a new one (this time, I didn't use FlashGot, so it might be a genuine bug)
Yes - if it's not in places, it's not going to expire.
Product: Firefox → Toolkit
WORKSFORME per comment 13
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.