User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 The following web site http://www.proxy2.de/archiv/ offers various script-launched downloads. Mozilla consistently returns an error indicating the "temporary file could not be saved because the source file could not be read". The download launches properly in IE 6+ Reproducible: Always Steps to Reproduce: 1.http://www.proxy2.de/archiv/ 2.Select "Download all scripts" icon 3.Message appears Actual Results: The error message appears. Expected Results: The download should launch.
Indeed I have had this, with a 200305 build. I think it was on Win98, but succeeded on Linux, or may have been the other way round. It may be related to file names, or cancelling then re-syarting download. Cannot repeat on http://www.proxy2.de/archiv/. Could it be a fault in the temp file naming algorithm? For me, this bug is extremely rare, But once it appears the browser seems to be jammed in this state. If this bug re-appears, I will try to provide less ambigous report.
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030604 But I did notice that the file name defaulted to scripts.zip.php instead of scripts.zip
I have just seen this bug on Linux with build 2003041008 (trunk) Here are some details: After download completed from a web page (Possibly a link off the following page: http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html will try to confirm, but the ftp site for downloads is down.) The following appeared in an error dialog: /tmp/f002n8wn.gz colud not be saved bacause the source file could not be read.Try again later, or contact the server administrator. While the dialog was open did the following: "lsof" command provides the following for this temp file: mozilla-b 3093 xxxx 39w REG 3,72 1619930 41797 /tmp/f002n8wn.gz Where xxxx is my user name. Manually copied the file using konqueror file manager, and succesfully extracted the file. Will upgrade to a more recent version soon, and next time, will try to get the permissions of the version too. This bug is extremely rare but annoying. It can be worked around, because the temp file can be copied. In terms of my cancel/restart download theory, this time it was a simple one-click download.
P.S. Someone should change the Component field in this bug: It is currently "Browser-General", should be "Download Manager".
I have the same bug under Mac OS X with 1.4RC2 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030612). I also observed it with earlier versions. The path of the source file that cannot be read varies, but it looks always pretty odd. Sometimes it points to a mail account directory, sometimes to another strange place where I would not expect downloaded files to be stored. It happens more often than it apparently does in the Windows case. It is reproducible to a high degree, but surprisingly I can sometimes download filed that failed on earlier attempts. Regards, Michael
15 years ago
This look suspiciously like a duplicate of bug 203689. If I'm wrong, please feel free to reopen this, but read that bug first to make sure they're really different. Thanks. *** This bug has been marked as a duplicate of 203689 ***