104248 - More cache space allocated than available profile space

Status: VERIFIED DUPLICATE of bug 100828

(Core Graveyard :: Profile: BackEnd, enhancement)

Description

[kirun]

0.9.4: When installing from new zipfiles to a user's personal space, mozilla by
default sets a large cache. System settings may be to have a much smaller
allocated profile space; for example at Uni we get 8Mb for all programs. Moz
should not exceed or hog this space. Alternatively, it could offer to put the
cache in a more generous disk allocation elsewhere.

Comment 1

[Conrad Carlen (not reading bugmail)]

There's probably a bug filed against cache on this problem. I can't seem to find
it though. I agree this is a serious problem and it goes beyond just the cache:
mail can put huge amounts of data in your profile dir as well.

This could be fixed *if* it was possible to have a "Move Profile" button in the
profile mgr UI. See bug 77924. Fixing that is quite a bit of work on the backend
because Windows & Unix use absolute file paths all over the place for
profile-relative files.

Gordon, you mentioned that it has been requested to place the cache elsewhere
via a pref. What do you think of just allowing the whole profile to move as this
would solve several problems at once?

Comment 2

[gordon]

I think the ability to move profiles is good.  However, I think many users will
still want to be able to store their cache directories in a different place than
their profiles.  I don't think the additional flexibility would hurt, once we
figure out the locking strategy (but that's a different bug).

Comment 3

[Ashley Bischoff (blog at handcoding.com)]

No dupes found. Marking NEW.

Conrad: -> Networking:Cache ?

Gordon: A pref for setting the cache directory is bug 46490.

Comment 4

[Conrad Carlen (not reading bugmail)]

There might be an easy way around this without getting into prefs UI and having
it change at runtime. As somebody suggested on bug 46490, you should be able to
make an alias (shortcut, symlink) to the "Cache" dir and move the actual one
wherever. The reason this doesn't work is that nsLocalFile only resolves aliases
at the leaf node. Either that, or nsILocalFile::Append() should resolve the leaf
before appending to it. If it was done with an alias, it would be possible for
the (probably) few people who need to do this but not clutter up the prefs UI
for those that don't.

Comment 5

[Conrad Carlen (not reading bugmail)]

The problem I mentioned about not being able to make an alias to the cache dir -
I'm working on that this moment. It's bug 100828. I'll make it a dup of that. As
far as having UI to allow the user to specify another location, that is or
should be another bug.

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

Comment 6

[K'Trina Medina]

Verified as a duplicate of 100828