74008 - when download is 98-99% complete, Mac app spins for several seconds

Status: VERIFIED DUPLICATE of bug 55690

(SeaMonkey :: UI Design, defect)

Description

[sairuh (rarely reading bugmail)]

i've been seeing this on and off --today am using 2001.03.29.08 comm bits on Mac
OS 9.0x. doesn't seem to be a problem on win32 or linux.

i'm not sure if this is a problem with FTP downloading or not. please reassign
as needed, thx!

1. go to the above url,
http://www.mozilla.org/quality/browser/front-end/testcases/xpapps-gui/download.html
2. single-click the "latest tar.gz ball" link.
3. in the resulting Downloading dialog, make sure "Save to disk" is selected,
and click OK.
4. select a download directory in the resulting file picker, and click Save.

result: the resulting Saving File [download progress] dialog appears [expected],
but when the download reaches 98-99%, the disks spins for about 10sec before the
download actually finishes.

Comment 1

[Doug Turner (:dougt)]

i thought that this was fixed.  Other platforms are not complaining.  /me 
guesses another mac nspr problem...

Comment 2

[sairuh (rarely reading bugmail)]

spoke with simon on this --prolly dependent on bug 55690.

another observation: this spinning occurred when i was saving to a volume other
than the startup volume of my Mac. when i saved to the desktop, or a folder in
my startup volume, i didn't encounter this.

Comment 3

[Simon Fraser [no longer active]]

dougt: this is not "another Mac NSPR problem". This is file download sucking. 
What happens is that when the user specifies to save a download to disk, and 
chooses a directory other than the default download directory, we still happily 
go ahead and save to the defefault download directory. Then, when the download is 
done, we move and rename the file into the user's chosen destination.

The disk thrashing that sairuh reports is happening because the location she 
chose for the final destination is on a different volume to the default download 
location. So we have to copy the file between volumes, which involves lots of 
disk thrashing.

This is yet another symptom of the really broke file downloading logic, that 
includes:
1. Name salting
2. Starting downloading before the user chooses a location, and hence...
3. Always downloading to the default downloads folder first.

Why don't we just bite the bullet, and behave like every other FTP application 
out there? Just download into the final destination with the final name, and be 
done with it.

Over to pchen

Comment 4

[Doug Turner (:dougt)]

simon, thanks for straighting this out.  I just like point the figure at mac 
nspr....  :-)

I also have to say that I TOTALLY agree that this downloading logic sucks ass.  
I am not sure what spark this drift from how ALL OTHER internet application 
work, but I think that we are doing the wrong thing.  We shouldn't start 
downloading until the user says where it should go. Does cp, or mv, start their 
business before you issue the command?  What happens the place we start download 
(prior to the user telling us where it should go) is write protected, or errors 
out?

Also, this whole salting downloads business.... why should we rename (eg salt) 
files when downloading? Salting is used is security to make things more 
difficult to crack. What real risk is there that we must salt downloads?  I do 
not see any, and I have not read about any. 

Comment 5

[timeless]

Um silly question... is it possible for a download session to change where it 
writes while it's downloading?

eg. we d/l 12% to a temp file. the user tells us where to write (and it's on 
another drive), we copy that 12% to the new file. [2% builds up], we copy that 
2% and then update the file writer to start writing to the correct file 
(actually, assuming we have binary seek we could probably start writing the 
incoming data immediately where it belongs and then copy over the start buffer 
when possible). when we're done, we kill the start buffer.

otoh, we could just ask the os to buffer the entire file in memory until the 
user picks a location (wouldn't this make more sense on most operating systems 
w/ decent vm?)

Comment 6

[Paul Chen]

Marking dup of 55690 because if that's fixed, we shouldn't see this problem

*** This bug has been marked as a duplicate of 55690 ***

Comment 7

[timeless]

vrfy dupe