I am downloading Oracle 9i for linux, there are 3 files to download, files 1 & 3 get fully downloaded, but file 2 never finishes to download, it causes the browser and download mgr to freeze up a minute or 2 into the download. Does anyone know why? File 1 is the second biggest file, file 2 is the largest and file 3 is the smallest.

these "files" should be iso disk images, rather large. is there any chance you are running out of disk storage?

Which area on the disk do these files get downloaded into? the /usr, not the swap, or the other area on the disk I forgot its name. I believe also that it might be disk storage.

Which browser are you using? If it is Mozilla then try a different one - I once pointed out to the Mozilla devs that under certain circumstances their downloader pointlessly writes the files both to /tmp/ AND to ~/.mozilla/somewhere/ - but it gets worse; on completion of the download, it tries to copy one of these temporary files to where you originally directed it to go to, so you can sometimes need THREE times the disk space a single copy of a file would normally require and you will usually require TWICE the space because of this incredible stupidity. Unfortunately, I was very sarcastic about it so out of spite, they probably never fixed it.

i have never seen mozilla download the same file simultaneously to multiple locations. For whatever reason, Moz always asks me where to store the file and puts it right there. In this case, I think the real problem is 3 iso's could be up to ~2GB. I supect t-bone probably has 1 partition, so "directory" is irrelevant. There are also erroneous concepts about directories versus partitions and "loading into swap"?? The best approach is to load 1 at a time, burn it to CD, rm , get the next.

http://bugzilla.mozilla.org/show_bug.cgi?id=69938 As I pointed out to the devs, it is/was possible to get mozilla to make 3 copies of a downloaded file under the 'right' circumstances. I distinctly remember how annoyed I was, watching the disk usage, as I downloaded a large file to partition a and saw /tmp on partition b filling up at the same rate as my cache in /home on partition c and finally partition a itself filling up with the actual target. Looking at the bug report, in which there are comments from people who do not even 'understand' the nature of the bug, I initially held out little hope for it ever being resolved but comment #234 has restored my optimism a little. So if t-bone's file 2 >> max(file 1, file 3) it would not be surprising if it had run into this problem. Anyway, you are no doubt right that burning each file to cd and deleting them one by one is a good idea.