1501277 - downloaded file gets deleted if name is same

Status: VERIFIED FIXED

(Firefox :: Downloads Panel, defect, P3)

Description

[kill_pink]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

(tested on firefox stable 62.0.3 (64bit),windows 10)
1. go to releases.ubuntu.com (or any site)
2. download a large file,save it as "a.iso" (like this one http://releases.ubuntu.com/bionic/ubuntu-18.04.1-desktop-amd64.iso)
3. cancel the download before the file is completely downloaded
4. download another file (like this http://releases.ubuntu.com/bionic/ubuntu-18.04.1-desktop-amd64.iso.zsync ), save it as "a.iso",let the file be completely downloaded.
5. check your file manger and verify that "a.iso" (the second one) is saved.
6. close firefox and "a.iso" (the second one) will vanish


Actual results:

"a.iso" (the second one) vanished


Expected results:

"a.iso" (the second one) must exist even after firefox is closed

Comment 1

[kill_pink]

file names must match ("a.iso" in this case),download location needs to be same

Comment 2

[Timea Cernea [:tbabos][inactive]]

Hi kill_pink,

Tested on latest Firefox Release 63.0. on Windows 10 x64. 
In my case, the first ISO file "vanished" (that had the download canceled) after closing and restarting Firefox. The second ISO file was there downloaded completely as expected. Can you please check again if it was not the same case on your side? 

Consider using a new profile and safe mode as well to avoid any custom settings that may be the cause of the issue.

Thanks!

Comment 3

[kill_pink]

Tested with new profile in safe mode & new private window. The bug was still there.
But there was no bug in normal browsing window.
So I have updated the information you need to reproduce the bug.


1. Open a new private browsing window. go to http://releases.ubuntu.com/bionic/ (or any site)

2. download a large file,save it as "a.iso" (like this one http://releases.ubuntu.com/bionic/ubuntu-18.04.1-desktop-amd64.iso) in any folder. If you check your target folder using a file manager you will see "a.iso" & "a.iso.part" .

3. cancel the download before the file is completely downloaded. do not restart or close the firefox private browsing window. both "a.iso" & "a.iso.part" will be automatically deleted after cancelling the download.

4. download another file using the same private window (like this http://releases.ubuntu.com/bionic/ubuntu-18.04.1-desktop-amd64.iso.zsync ), save it as "a.iso" in the same folder, filenames must match including file extension, let the file be completely downloaded.

5. check your file manger and verify that "a.iso" (the second download) is completely downloaded & saved. there will be only one "a.iso" in that folder & there will be "a.iso.part".

6. close firefox. if you check you will see "a.iso" (the second download) is automatically deleted from the target download folder after closing firefox.

Comment 4

[kill_pink]

correction: the step 5 of the previous comment will be:

5. check your file manger and verify that "a.iso" (the second download) is completely downloaded & saved. there will be only one "a.iso" in that folder & there will be no "a.iso.part".

Comment 5

[Timea Cernea [:tbabos][inactive]]

Reproduced on latest Nightly 65.0a1 (2018-10-28) on Windows 10 x64.

As the reporter mentioned, the a.iso file will be deleted after restarting firefox. 
Thanks kill_pink for the investigations and adding reliable steps to reproduce!
WIll add it to a component so the developers can take a look at this issue.

Comment 6

[:Paolo Amadini]

Thank you for reporting the issue! We don't have a team assigned to this area right now, but this is something we should definitely look into at some point.

Comment 7

[Alice0775 White]

STR

1. Start download http://ftp.mozilla.org/pub/firefox/nightly/2019/05/2019-05-01-04-21-12-mozilla-central/firefox-68.0a1.en-US.win64.zip
2. Cancel the download while the downloading is processing(Ctrl+J > Click on [x] button of the download entry)
3. Again download same file http://ftp.mozilla.org/pub/firefox/nightly/2019/05/2019-05-01-04-21-12-mozilla-central/firefox-68.0a1.en-US.win64.zip
4. Wait for finishing of the download
   --- observe, the downloaded file is successfully created
5. Clear Downloads (Ctrl+J > Click on [Clear Downloads])
   --- observe, the downloaded file is unexpectedly deleted

Comment 8

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a6bb991ed09261b1ee7c90a0ed88fb82465e3877&tochange=22b96cee9f15d9aa64651756762f001f2e9486a2

Regressed by:e406af77d28ddd1b59a432a4523b8a09ddf05e54 Johann Hofmann — Bug 1139913 - Downloads with partial data should still keep the placeholder on disk. r=mak

:Paolo Amadini, Your patch seems to cause the data loss. Can you please look into this?

Comment 9

[:Paolo Amadini]

Redirecting to Marco who is now the triage owner of the module. This may have the same cause as bug 1485555, even though the two are different. As it is the case for the other bug, there isn't a team assigned to this area of the code, but he may be able to find someone to look into this.

Comment 10

[Masatoshi Kimura [:emk]]

Attachment: Bug 1501277 - Don't remove non-placeholder if placeholder is expected. r?mak

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/63b018eec45a
Don't remove non-placeholder if placeholder is expected. r=mak

Comment 12

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/63b018eec45a

Comment 13

[Masatoshi Kimura [:emk]]

Comment on attachment 9068718 [details]
Bug 1501277 - Don't remove non-placeholder if placeholder is expected. r?mak

Beta/Release Uplift Approval Request

• User impact if declined: Dataloss, sometimes downloaded files would be deleted unexpectedly.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Basically this change will just revert the pre-bug 1139913 behavior.
• String changes made/needed: none

Comment 14

[Julien Cristau [:jcristau]]

Comment on attachment 9068718 [details]
Bug 1501277 - Don't remove non-placeholder if placeholder is expected. r?mak

old issue, but seems bad enough; approved for 68.0b9

Comment 15

[Timea Cernea [:tbabos][inactive]]

Verified - Fixed on latest Nightly 69.0a1 (2019-06-09) (64-bit) on Windows 10 x64, Mac OS 10.13 and Ubuntu 18.04.
Updating flag and waiting for fix on Beta.

Comment 16

[Oana Pop-Rus]

https://hg.mozilla.org/releases/mozilla-beta/rev/aeea3bdffd87

Comment 18

[Timea Cernea [:tbabos][inactive]]

Verified - Fixed on latest Beta 68.0b9 (64-bit) on Windows 10 x64, Mac OS 10.13 and Ubuntu 18.04.