159432 - UI freezes at end of download to slow network drive

Status: RESOLVED DUPLICATE of bug 103766

(Core Graveyard :: File Handling, defect)

Description

[Chris]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020722
BuildID:    2002072204

I have a server running smbd sharing a large drive where I save many files. 
When downloading a file, Mozilla apparently downloads to a temp file on the
local drive, then copies the file to the destination.
When the final destination is a slow network drive, the whole UI freezes during
this final copy, making it appear the program has hung, and inviting a
Ctrl-Alt-Del.  After the file finishes copying, the UI responds to events as normal.

Reproducible: Always
Steps to Reproduce:
1. Find a largish (10Meg?) file to download
2. Save it to a remote disk over a 10Mbit network
3. Note that UI does not respond for a while at the end of said download.

Actual Results:  UI freezes at the end of the download as it copies the
downloaded file to the desired location.

Expected Results:  Mozilla should copy the file in the background or something,
retaining UI interaction.



IE spawns a "Copying file" process like the ones Explorer uses.
Netscape does not use a local temp file.

Comment 1

[Boris Zbarsky [:bzbarsky]]

yeah, at least we should put the copy on a different thread....

Comment 2

[Michel Poleur]

I have the same problem on local drives. I recently downloaded a 250 MB file
(Lotus Domino) and the UI froze for two or three minutes.

Comment 3

[Steve McMillen]

I see this problem as well.  I think this is a new issue since an earlier
mozilla.  Definitely new with Netscape which used to save the file to the final
target location.  

I think the browsers behaviour was changed so that it now saves the file to a
temporary location on the local drive and then to upload the file from the local
drive to the target network drive once the download is complete.  I'd much
rather see the browser write directly to the network location.  This would solve
the problem described here.  

Maybe the change was to prevent a partial file from showing up in the target
location where a user might try to open it.  I think a better way to solve this
problem is to write the file with a differnt file extension (such as .tmp) and
then do a rename at the end.  Since the file will be on the destination drive,
the rename should not incur any delay.

Comment 4

[OstGote!]

IMHO this is a dupe of bug 103766. The problems described there occur if you
have a slow disk/network drive/large file.

Comment 5

[Boris Zbarsky [:bzbarsky]]

yeah, that's it.

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