195179 - download needs twice the space; cancel leaves one in the cache

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[reb]

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.

Comment 1

[R.K.Aa.]

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

Comment 2

[benc]

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)?

Comment 3

[reb]

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).

Comment 4

[reb]

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.

Comment 5

[benc]

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.

Comment 6

[OstGote!]

(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?

Comment 7

[OstGote!]

Marking WFM. Remaining issues are addressed by other bugs.