288152 - Saving files always to desktop creates two files for downloads in progress

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[Simon]

Firefox's download manager creates two files for in-progress downloads - a 0
byte file with the name/path of the destination, and a file with the same path
but with .part appended.

Spotted this on a recent CVS BeOS build, it also happens on the latest Windows
nightly build, so must be a cross-platform thing.

Comment 1

[Simon]

The old (and I assume, desired) behaviour is to just have the .part file while
the download is in progress, and then remove the part extension when it has
finished. Having 2 files is confusing, and the apperance of the file with the
final expected name misleads the user to believe the download is complete.

[Sorry for the 2 posts, pressed return instead of backspace in the new bug form]

Comment 2

[Michael]

You only get the two files if you set the Download Manager to always save to
your desktop. If you change the Download Manager to prompt you for the directory
instead then you only get the ".part" file until download is complete. (Please
note bug 284089 when playing around with these settings). This happens with the
Firefox 1.0 release (branch) as well as on the latest nightlies (trunk). You
might want to change the summary to reflect this.

Comment 3

[Patrick]

[e-mail] : please always provide a comment when you change the summary.
That makes it possible to track summary changes from the main bug page.

Correcting small typo in the new summary "lways" -> "Always"

Comment 4

[TGOS]

Altered summary to really describe the bug.

Severity is not major! It's annoying, but not a real problem.

This should be really, really easy to fix. Could someone please take care of
that bug? It's annoying me for months, too.

Comment 5

[Simon]

I looked at the cross-platform download manager code and got scared before I
initially reported the bug. I actually think it's quite a serious quality bug,
and can be very misleading, as I mentioned in comment #2. That was why I
considered it major (not that it was destructive or anything, but that it was
very visible and a source of confusion for the user).

Comment 6

[mark]

Should be a blocker for sure. A bit abnormal if you have some *.part on desktop.
Confusin for dummyuser!

Comment 7

[Mike Connor [:mconnor]]

Herein lies the problem: when autodownloading foo.exe, if you then decide to download another foo.exe we check for whether foo.exe exists, and if it does, we'll increment to foo(2).exe so they don't collide.  I'll agree that, even temporariliy, exposing the .part file is a little lame, in the exposing implementation deetails to the user realm, but it's not a blocker.

There was a request a while back to make the .part files hidden, except that users can then end up with large hidden files sucking up diskspace.

Comment 8

[Jo Hermans]

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

Comment 9

[Shawn Wilsher :sdwilsh]

WONTFIX - comment 7 summarizes this well.