Open
Bug 1010040
Opened 11 years ago
Updated 3 years ago
Firefox 29 deletes .part files when i press "clear downloads"
Categories
(Firefox :: Downloads Panel, defect)
Tracking
()
NEW
People
(Reporter: rckstone, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807
Steps to reproduce:
Start a video file download. FF creates .part file
start watching the video in .part file while downloading using players like vlc
download completes but .part file cannot be renamed as it is being used.
now close the video player.
press "clear downloads" in download manager OR close and restart Firefox 29.
Actual results:
The .part file gets deleted.
Expected results:
.part file should not be deleted as it was in earlier versions.
Comment 1•11 years ago
|
||
Paolo, is this reasonably fixable? I would expect it to be pretty hard, and not that many people will know how to make use of the part files (and indeed, they will not be useful in many cases), so I'm not sure it makes sense to do this...
Component: Untriaged → Downloads Panel
Flags: needinfo?(paolo.mozmail)
Comment 2•11 years ago
|
||
(In reply to :Gijs Kruitbosch from comment #1)
> Paolo, is this reasonably fixable? I would expect it to be pretty hard, and
> not that many people will know how to make use of the part files (and
> indeed, they will not be useful in many cases), so I'm not sure it makes
> sense to do this...
Pressing the "clear downloads" button makes Firefox lose track of the downloaded file entirely, thus we need to delete the partially downloaded data from disk to prevent it from filling up disk space unnecessarily. Even if the file is downloaded to the temporary directory, the application is responsible for ultimately deleting it.
Also, I think that the "clear downloads" button should be expected to clear partially downloaded data for interrupted downloads in any case. Technical users can just close the browser to unlock the file, and copy the partially downloaded file elsewhere, if they don't want this to happen.
Note that "clear downloads" does not delete ongoing downloads at all, so their partially downloaded data is preserved.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(paolo.mozmail)
Resolution: --- → WONTFIX
many times i cannot wait for the file to completely finish download due to the internet speeds in my geo.
earlier behavior was very useful , suddenly i have to change my browsing/downloading style.
as far as i am concerned Clear downloads should only delete partial interrupted downloads,
NOT the files that have completed download and just fails to rename it.
is there at least a about:config option to revert back to previous behavior?
if not can this be part in about:config so that i can choose the way it should work.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Comment 4•11 years ago
|
||
(In reply to RockStone from comment #3)
> as far as i am concerned Clear downloads should only delete partial
> interrupted downloads,
> NOT the files that have completed download and just fails to rename it.
Ah, I think I misunderstood the original steps to reproduce, sorry. In your case the download was completed, but the final rename failed because, on Windows, having the file open in another application prevents it from being renamed (but not from being written to).
To be clear, accessing a file while it's being downloaded is handy, but it's not a use case we're explicitly supporting. In other words, watching a video while it is being downloaded works now, but it could stop working in the future. This might be a really nice feature for a video downloader add-on, if an add-on author wants to provide and maintain it.
That said, what we might want to improve here is the process of resuming almost-completed downloads for which the final renaming failed, either manually or automatically. But I'm not sure exactly how crucial is this, and as Gijs said this can require quite a lot of effort.
Updated•11 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•