Open Bug 1474765 Opened 6 years ago Updated 2 years ago

Consider checking whether the placeholder is zero bytes in size before deleting it

Categories

(Toolkit :: Downloads API, defect, P5)

61 Branch
defect

Tracking

()

People

(Reporter: vtan000, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

Start a download from a web site. Save the file as its original filename in the Downloads folder. Disconnect from the internet so that the file is incompletely downloaded. Reconnect to the internet. Start another download but save the file under a different name (I actually did this by accident but it doesn't matter as the bug is still the same). After the download finishes, rename the completed file to its original name. Go to the Download list. Delete the entries for both the second download and the first (incomplete) download. You should find that the file has now been deleted and you'll need to download it *again*.


Actual results:

A file that was completely downloaded ends up deleted from the file system when it should not be, which forces me to download it *again*.


Expected results:

The completely downloaded file is not deleted and left alone under its original name (after having been downloaded under a different name).
(In reply to Vincent Tan from comment #0)
> After the download
> finishes, rename the completed file to its original name. Go to the Download
> list. Delete the entries for both the second download and the first
> (incomplete) download. You should find that the file has now been deleted
> and you'll need to download it *again*.

Just to be clear, you downloaded file "A" (incomplete) then you start downloading again "A" and rename to "B". After download finishes you rename it to original name "A" (in my case it doesn't let me rename to "A" saying name is already taken). So now there are two entries and you deleted them both or just delete one? 

I tested this on following user agent and couldn't reproduce this bug (as per my understanding)
Build ID 	20180704003137
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0

If you could attach the screen cast of this bug that would be great. Thanks!
Flags: needinfo?(vtan000)
correct. The file to download is named A and I have Firefox set to ask me where to download so I start the second download and named it B. I'm not sure why, but somehow I ended up with the first incomplete file having no file-system file named A so that it was possible for me to rename B to A. It may be that I tried to resume the download on the first incomplete file and this fails which in turn caused the file-system file to be removed? I don't recall if there was a "A.part" file before I did the renaming.

In any case, the Download list has 2 entries: one for the first incomplete, and one for the complete download. I usually clean up my Download list so I selected both download entries and deleted them (using the 'del' key FWIW). Then I went back to the Finder and found that the downloaded file no longer existed.

I suspect that deleting the incomplete file entry causes the file-system file to be deleted because that is the normal Firefox behaviour. In this case, the problem is that the file is completely downloaded so the deletion should not occur (the file size of the download is not indeterminate so Firefox should be able to tell a complete download from an incomplete one before it tries to delete a downloaded file).

I usually encounter this bug a few times each month so I decided to file a report (it gets annoying to have to download a file again). If it happens again, I'll try to see if I can add more details to make it more reproducible. Unfortunately, most of my downloads aren't incomplete so this occurs on an occasional basis which makes it hard to me to be more specific.
Flags: needinfo?(vtan000)
Sounds as Intermittent bug. Setting the component to Toolkit:Downloads API so someone can look into it. Please feel free to change it to more appropriate component.
Component: Untriaged → Downloads API
Product: Firefox → Toolkit
(In reply to Vincent Tan from comment #2)
> I suspect that deleting the incomplete file entry causes the file-system
> file to be deleted because that is the normal Firefox behaviour.

Yeah, in the situation you describe, where you have renamed the file manually, the browser probably expects a zero-byte placeholder to be in place of the file that is then deleted. We may check whether the file is actually zero bytes before deleting it, but we can do this only when using ".part" files, and not all download code paths will create one.

For downloads with no ".part" file that have been interrupted, we don't know the expected final size on disk, so we can't know if the file has been renamed and replaced with something different.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5
Summary: Firefox deletes a downloaded file that has completed when I delete the file from the Downloads list (instead of not deleting the file) → Consider checking whether the placeholder is zero bytes in size before deleting it
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.