1768414 - Temporary files with the extension "part" are left in the Downloads directory (moving files fails if the download is still in-progress when confirming a destination folder)

Status: RESOLVED INCOMPLETE

(Toolkit :: Downloads API, defect)

Description

[jiri.j.s]

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

Steps to reproduce:

In Firefox, I have activated the "Always ask where to save file" option.
When I click on a download link in Firefox, a window pops up asking where I want to save the file.

Actual results:

Before I can even enter the desired location, the file starts downloading to the Downloads directory as a temporary file, i.e. with a random name and the extension "part". The fact that the download to the Downloads directory is already in progress is not visible in Firefox - no information about it appears in Firefox's Library Downloads.
As soon as I specify the location where I want to save the file, the download to the Downloads directory is aborted (a parasitic file with the extension "part" remains in the Downloads directory) and the message "Failed" appears in Library Downloads Firefox. After clicking "Retry" will the file be downloaded to the desired location.
If I wait to specify a location to save the downloaded file until it is fully downloaded to the Downloads directory, the file is moved from the Downloads directory to the desired directory. In this case, no parasitic file with the extension "part" remains in the Downloads directory.

Expected results:

The downloaded file is properly placed in the desired location and no parasitic files with the "part" extension remain in the Downloads directory.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[:Gijs (away/busy until Mar 10)]

Is the default downloads directory just the Downloads folder in Windows? And is that a local drive (ie not a network share)? What about the location where you're moving the file - is that a network share? Or are you using RAM disk software for either of those two directories?

Comment 3

[jiri.j.s]

Both folders, i.e. the standard system Downloads folder as well as the folder where I want to save the downloaded file, are local — placed on the local SSD. I do not use any RAM disk.

Comment 4

[:Gijs (away/busy until Mar 10)]

When the download fails, are there any errors in the browser console (not the regular devtools one, the browser one - https://developer.mozilla.org/en-US/docs/Tools/Browser_Console ; ctrl-shift-j to open it on Windows) ?

Comment 5

[jiri.j.s]

To answer correctly, I did further, more detailed tests and found that Firefox's download behavior varies according to the site I'm downloading from and/or the type (extension) of the file, as follows:

1. There is no problem when downloading a video file “Dechberoucí motýlí roj.mp4” from https://uloz.to/file/rWhIAJDhUwUY/dechberouci-motyli-roj-mp4# link. Even though the download starts before the destination directory is specified and goes to the Downloads directory, once the destination directory is specified, the part of the file that has been downloaded so far is moved to the destination directory and continues there without any problems. No trace is left in the Downloads directory - everything is OK.
2. When downloading the executable file calibre-64bit-5.42.0.msi from the link https://calibre-ebook.com/download_windows64, the download starts before the destination directory is specified and goes to the Downloads directory. After entering the destination directory, Firefox reports that the download failed. The part of the downloaded file that has been downloaded so far is not moved anywhere and remains in the Downloads directory as an incomplete parasite file with a random name and extension PART (e.g.: X-cKqDYp.msi.part). An empty file (zero-length file) with the correct name (without the PART extension) is created in the destination directory. After the Retry command, the download starts from the beginning and the file is saved to the previously specified destination directory without further querying the destination directory.
   Here is the content of the browser console:
   1653061974948 addons.xpi WARN Checking C:\Program Files\Mozilla Firefox\distribution\extensions for addons
   Error: Can't find profile directory. 2 XULStore.jsm:66:15
   Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml
   NS_ERROR_FAILURE: Ignore PDF.js for this download. PdfStreamConverter.jsm:1121
3. If when downloading the calibre-64bit-5.42.0.msi file from the link https://calibre-ebook. com/download_windows64, I wait to enter the destination directory until the entire file has been downloaded — I have to verify this in the Downloads directory using the file manager, because the fact that the download has been started, is in progress, and has even finished is not reported by Firefox — and only then do I finish entering the destination directory, the completely downloaded file is moved from the Downloads directory to the destination directory and no trace of it is left in the Downloads directory.

So I consider the following to be problematic:

• The fact that the download starts before the destination directory has been specified.
• The fact that the download has started, is in progress, and even that it has already finished, is not reflected in Firefox (the fact that the download is already in progress can only be detected by looking in the Downloads directory using the file manager).

I find the change in Firefox's download mode to be very unfortunate, where even temporary files are no longer downloaded to the TEMP directory, but to the Downloads directory, because all aborted or failed attempts to download files now leave garbage in the Downloads directory. The place where such garbage belongs is in the TEMP directory, which is the designated place. During regular maintenance, I delete the entire contents of the TEMP directory without having to worry about what can and cannot be deleted - simply because there is only garbage in the TEMP directory. This is not the case with the Downloads directory. Like any user, I have valuable files there.

I don't understand why Firefox introduces a way of working that forces users to distinguish between desirable files and garbage in the Downloads directory. Not only is this annoying, but it risks a mistake where the user deletes something valuable with the garbage.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[:Gijs (away/busy until Mar 10)]

(In reply to jiri.j.s from comment #5)

To answer correctly, I did further, more detailed tests and found that Firefox's download behavior varies according to the site I'm downloading from and/or the type (extension) of the file, as follows:

1. There is no problem when downloading a video file “Dechberoucí motýlí roj.mp4” from https://uloz.to/file/rWhIAJDhUwUY/dechberouci-motyli-roj-mp4# link. Even though the download starts before the destination directory is specified and goes to the Downloads directory, once the destination directory is specified, the part of the file that has been downloaded so far is moved to the destination directory and continues there without any problems. No trace is left in the Downloads directory - everything is OK.
2. When downloading the executable file calibre-64bit-5.42.0.msi from the link https://calibre-ebook.com/download_windows64, the download starts before the destination directory is specified and goes to the Downloads directory.

Are you using the same destination directory for both of these cases? Firefox will remember directories on a per-domain basis so I wonder if there is something special about the location where you're saving the installers that is different from where you're saving the mp4 that explains the brokenness.

Unfortunately I cannot reproduce - both of these cases work correctly for me.

After entering the destination directory, Firefox reports that the download failed. The part of the downloaded file that has been downloaded so far is not moved anywhere and remains in the Downloads directory as an incomplete parasite file with a random name and extension PART (e.g.: X-cKqDYp.msi.part). An empty file (zero-length file) with the correct name (without the PART extension) is created in the destination directory. After the Retry command, the download starts from the beginning and the file is saved to the previously specified destination directory without further querying the destination directory.

So, this is bad, and I would like to fix it, but it's difficult to know how given that I cannot reproduce the problem.

So I consider the following to be problematic:

• The fact that the download starts before the destination directory has been specified.
• The fact that the download has started, is in progress, and even that it has already finished, is not reflected in Firefox (the fact that the download is already in progress can only be detected by looking in the Downloads directory using the file manager).

Both of these have always worked like this. Firefox only knows that something is a download when it receives a response from the server, and at that point it needs to start saving that response somewhere - ie it is already downloading. It can't "block" on receiving a response from the user; that could take a very long time and cause the http connection to time out, and http gives you no guarantee that if you make the same request a second time, you get the same response (e.g. cookies could have expired, you could be logged out, your limited time internet could have run out, whatever). So we download in the background. If you cancel the download the files will all be removed and the request cancelled.

I find the change in Firefox's download mode to be very unfortunate, where even temporary files are no longer downloaded to the TEMP directory, but to the Downloads directory, because all aborted or failed attempts to download files now leave garbage in the Downloads directory. The place where such garbage belongs is in the TEMP directory, which is the designated place. During regular maintenance, I delete the entire contents of the TEMP directory without having to worry about what can and cannot be deleted - simply because there is only garbage in the TEMP directory. This is not the case with the Downloads directory. Like any user, I have valuable files there.

This is bug 1738574 and as of Firefox 102 (released next week) you can force Firefox to use the temp folder behaviour using enterprise policy or the pref listed in that bug in about:config ... but it seems unlikely to me that that would fix the issues you're having here with downloads failing - if it does, I would like to know!

Comment 8

[:Gijs (away/busy until Mar 10)]

Unfortunately without more details we can't fix something here. We can reopen the bug if more details become available.