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.

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

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.

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.

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

yeah, that's it. *** This bug has been marked as a duplicate of 103766 ***