334835 - Download Manager should not delete modified/moved files, or files it didn't create

Status: NEW

(Toolkit :: Downloads API, defect, P3)

Description

[Lloyd Wood]

I'm downloading a large 41MB file from an IIS webserver via a very slow satellite link that also appears per-session rate-limited (12KB/s or so). I've been trying to download this file multiple times to multiple locations on disk, but the Download Manager eventually gives up, and the transfers appear 'stuck'. Pausing/resuming them doesn't help.

Eventually, I have the entire file downloaded - the length is right and is the complete file. Happily, I tidy up and move the file, and cancel the 'stuck' transfers in the Downloads window to remove the partial copies - and watch in horror as the completed file vanish in front of my eyes. It was one of the 'stuck' transfers. Obviously, I shouldn't have moved files around before cancelling; I wasn't expecting this deletion to happen. (Old-time Mac user on lame Windows filesystem. On Windows, the location matters; on a Mac, you can move files around. But nevermind.)

A sanity check should be introduced here: check the filesize of the download to be cancelled. Don't automatically delete a cancelled download when its filesize does not match the filesize the download manager believes it has downloaded. Any difference in filesizes (user modification in another program? renamed files? moved files? Who knows.) is an indication that caution is needed and a 'Something appears to have changed the size on this cancelled file on disk. [Delete] [Leave in place]' dialog is needed.

Comment 1

[Justin Kerk]

*** Bug 313286 has been marked as a duplicate of this bug. ***

Comment 2

[Justin Kerk]

Duping bug 313286 to this even though it's older, because this has a better problem description

Comment 5

[JD]

Moving the file to another directory on any Unix/Linux system, where the destination directory is within the same filesystem, only changes the
pathname, but not the inode. The file descriptor in the "stuck" download
manager is still pointing to the same inode, thus the same file.
When you cancelled the download, the download manager happily deletes the
inode.

A workaround solution is this:
Once the file is fully downloaded, copy it to a file of a different name.
You do not even have to copy it to some other directory. Even a single caharacter changed or added in the target name will still create a NEW
file, of a different inode. Thus if you cancel the download in the download manager, it will only delete the original downloaded file, and not the copy.
Another solution is to move the file to a directory that is in a different filesystem. That will create a whole new inode for the file in the target
directory which is on a different file system (such as another partition, or a USB stick), ...etc.

Comment 7

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

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 8

[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 BugBot documentation.

Comment 9

[Marco Bonardo [:mak]]

Not sure if .part downloading now avoids this case, but it's worth tracking it anyway, even just to add test units in case.