User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030213 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3b) Gecko/20030213 Like solved bug 138117, I see the same in 1.3b today. Downloads in progress write to one /tmp file and another in cache. Cancel leaves the incomplete cache one. Hence need to keep a backup browser (Comm 4.x, lynx) to do really large downloads. I happen to keep my cache under /tmp, so another work-around is to move the cache to a different disk partition, assuming you have one with space available, so the two download copies can complete (don't like browser slowdown from using a non-tmpfs cache though, could use a separate profile or separate user account configured for this purpose). That other bug is primarily about removing the cache version *after* complete. This bug in contrast is about downloads that can't even get to complete, due to twice the space required *during* download. Likewise that bug comments about up to three copies may be required considering the user's requested final target. Again, by constrast this bug is not addressing what happens *after* completion to get the result to the user's requested final target file. However I do observe Comm 4.8 downloads only/directly into the user's target, while Moz1.3b never does so, so Moz often again requires typically twice as much disk while coping from a compeleted download in /tmp to the user's target. Haven't benchmarked it, but writing same data to two files must incur some performance hit also. I observe the cache-version is world-readable, while the second copy in /tmp is only user rw. Probably (I haven't checked) the cache version permission is set by my process umask? Which is fine IMO as a way to control it (hence no security issue?). Reproducible: Always Steps to Reproduce: 1. Start downloading a file large enough to take several minutes 2. Monitor recent large files in /tmp and the cache, observe two files growing in near synchronization. List their inodes to verify they are distinct/separate files. 3. Cancel the download, observe the incomplete cache file remains. Actual Results: Mozilla requires twice the space to download as Comm 4.x. Large downloads fail in Mozilla (no disk left), where Comm 4.x would have no trouble. Cache gradually littered with incompletes, wasting space until cleaned. Expected Results: Download into one copy (either cache only or /tmp only). Remove this single file if cancelled.

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

So you are saying that complete downloads are appear from cache and are removed, and incomplete downloads appear in cache and remain? Also, does the 'clear cache' button remove the stub files? Have you tried other platforms (like Windows, Linux, Mac OS X)?

I have not tried other platforms. In a test right now (using 1.3b to download 1.3, only 16M) the cache copy remains also after successful download (whether cancelled or not); and clearing the cache does remove the cache file in both cases (cancelled or not, though I see an old/large PDF not cleared from my cache: probably a separate issue).

Additional possible case I'll test for within a few days: does cache file not get cleared if the download aborted by out-of-disk.

downloads don't belong in cache, so this would be solved by bug 55307. I would assume that all downloads (complete or incomplete) would be left in cache, and removing them would be a routine issue for cache. I'm getting up to speed on cache bugs, so I will look for that.

(In reply to comment #0) > Downloads in > progress write to one /tmp file and another in cache. That is bug 55307 (and bug 69938). > Cancel leaves > the incomplete cache one. That is still the case for all versions. Tested with 1.4.1 and 1.7b on WinNT. But if the cache limit is reached, the (incomplete) files are automatically deleted. If you try "Clear Cache", all files will be deleted (in fact, the whole cache directory is erased and newly created). (In reply to comment #5) > I would assume that all downloads (complete or incomplete) would be left in > cache, and removing them would be a routine issue for cache. It is already (I think) a routine job if the size limit is reached. So WFM?

Marking WFM. Remaining issues are addressed by other bugs.