downloaded file gets deleted if name is same

VERIFIED FIXED in Firefox 68

Status

()

defect
P3
major
VERIFIED FIXED
10 months ago
2 months ago

People

(Reporter: kill_pink, Assigned: emk)

Tracking

(Blocks 1 bug, Regression, {dataloss, regression, reproducible})

57 Branch
Firefox 69
Desktop
Windows 10
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 wontfix, firefox65 wontfix, firefox66 wontfix, firefox67 wontfix, firefox67.0.1 wontfix, firefox68 verified, firefox69 verified)

Details

Attachments

(1 attachment)

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
file names must match ("a.iso" in this case),download location needs to be same
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!
Flags: needinfo?(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.
Flags: needinfo?(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".
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → File Handling
Ever confirmed: true
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.
Priority: -- → P3

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
Severity: normal → major
Component: File Handling → Downloads Panel

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?

Has Regression Range: --- → yes
Has STR: --- → yes
Flags: needinfo?(paolo.mozmail)
Keywords: regression
Regressed by: 1139913
Version: 62 Branch → 57 Branch
OS: Unspecified → Windows 10
Hardware: Unspecified → Desktop

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.

Flags: needinfo?(paolo.mozmail) → needinfo?(mak77)
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Flags: needinfo?(mak77)
Pushed by VYV03354@nifty.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/63b018eec45a
Don't remove non-placeholder if placeholder is expected. r=mak
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69

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
Attachment #9068718 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Flags: in-testsuite+

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

Attachment #9068718 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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.

Flags: qe-verify+
Duplicate of this bug: 1558004

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
You need to log in before you can comment on or make changes to this bug.