Closed Bug 74085 Opened 23 years ago Closed 19 years ago

[Win] Disk cache should use local directory (CSIDL_LOCAL_APPDATA)

Categories

(Core :: Networking: Cache, defect, P1)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: ajbu, Assigned: darin.moz)

References

Details

(Keywords: helpwanted, perf, Whiteboard: [cache])

Currently, the disk cache directory is set by default as a subdirectory of the 
profile directory. 
At work I have this directory set to a network drive to use my application data 
on different computers. For performance the cache data should not be written to 
that network drive, but to a local directory.
On Windows the location of this directory is currently retrieved from 
SHGetSpecialFolderPath using CSIDL_APPDATA (nsSpecialSystemDirectory.cpp).

For Windows 2000 there is an ID CSIDL_LOCAL_APPDATA to retrieve a local Appdata 
path. This should probably be used as bases for a local profile/cache directory.

From the Windows 2000 guidelines: (attachment 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=26342)

CSIDL_APPDATA
As part of the User profile, this folder will roam.  Use this folder to store 
all user-specific application preferences. For example, if a user can specify a 
custom dictionary to be used in your application, you should store it here. 
That way if the user roams from computer to computer, their dictionary will 
roam with them. This also allows other users to have their own individual 
custom dictionaries.

CSIDL_LOCAL_APPDATA
This folder is for application data that does not roam. It is still part of the 
User profile, so this is still per-user information. Application data that is 
machine-dependent, such as user specified monitor resolution, should be stored 
here. This data must not roam because different machines have different 
monitors. In addition, large blocks of data which can easily be re-created 
should be placed here to minimize download time that is incurred when roaming. 
For example, Internet Explorer keeps its cache of downloaded html/gif pages 
here so that they don't roam with the user.  But the smaller cookie and history 
lists are stored in CSIDL_APPDATA so that they roam.


I know there is a pref "browser.cache.directory" but I think this should be the 
default directory.
Whiteboard: [cache]
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Disk cache directory should default be set to local computer directory → [RFE] Disk cache directory should default be set to local computer directory
Cache pref work is scheduled for 0.9.1.
Target Milestone: --- → mozilla0.9.1
*** Bug 66176 has been marked as a duplicate of this bug. ***
This bug is related to bug 46490, which indicated the need for users to select a 
cache directory in prefs.
Chris, Conrad, how feasible is this for Windows & Linux in the 0.9.1 timeframe?  
I think most Mac users tend to put their profile on a local drive already. Do we 
need to add another special system directory?  Could a "safe" local default even 
be determined on Linux?

If the cache folder is put on a network drive, there's almost no point to caching 
(of course it appears the same can be said for IDE drives under win98).
->0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
It's plenty feasible on Mac. You can tell if a volume is remote or not. In order
to do this, I think we should add a directory services key for the cache dir.
Since this is normally in the domain of the profile mgr, profile mgr would first
attempt to make the cache dir as a subdir of the current profile dir. If the
profile dir was remote, it would then resort to making a local dir.
Linux will have many different file and user configurations,
I think the best thing is to ask the user to find some local
space.  This can be done at install time, or first-run time.
Maybe put up a dialog saying "set cache directory to local
file system for XX% performance speedup using YYYY pref".

E.g. you can't just take over /tmp/mozilla, that partition
might be full, it might not be writeable, who knows.
Priority: -- → P3
I think there are still too many issues to work out before the 0.9.2 code
freeze.  Moving to 0.9.3.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla1.0
This needs to be resolved sooner than later, because an increasing number of
customers seem to be enterprise users that are using LAN-based file sharing.

For multi-user operating systems, what we really need is some way of reading a
system-admin level pref.

Here's my current take:

MacOS: nobody I know puts their profile on an appleshare server. It would be
just too painful for a company to have their users continuously using profiles
over AFP.

Linux: probably a simple selector on profile creation:

"Store cache data locally (/tmp or /var/tmp) or in the home directory?"
Also, as far as NFS goes, you can parse the results of mount -a for the server
hostname.

Windows, it sounds like they got that worked out already. lets imitate IE.

Keywords: nsenterprise
Fwiw, see bug 89903 (Slow Page Load With Cache on Remote Drive).
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Keywords: nsenterprise-
*** Bug 112844 has been marked as a duplicate of this bug. ***
This is not a RFE this is a real bug. The cache should not be stored on the
network drive this causes a lot of unnecessary network traffic and impacts the
performance of the cache.

Most large networks don't want this extra network traffic and therefore will be
an important reason for large organisations to decide to not deploy Mozilla/NS6
on their networks.

Nominating for 0.9.8 because such an important change to the cache should be
implemwnted before 1.0 in case it brings in any unexpected regressions.
Severity: enhancement → normal
Summary: [RFE] Disk cache directory should default be set to local computer directory → Disk cache directory should default be set to local computer directory
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
This is probably more a problem for unix/NFS scenarios, marking Linux.
I stand by my last comment, we should probably ask the user what
to do on install, or at first-startup.  The user may or may not have
access to local disk space, and it might be a complicated question
for some users.
OS: Windows 2000 → Linux
This bug was filed by a Windows user for getting the cache to use a local
directory on Windows (like IE does). Windows has a notion of a local prefences
directory (that always resides on a local disk) and a global preferences folder
that can reside on a network.

The situation of how to fix this is clear cut on Windows the OS specifies the
correct directory for this data and therefore we should respect this setting. In
Linux it is less clear cut $HOME may or may not be a local drive and if it's not
local you can't just assume location is available for caching.

I think we should just keep this bug open for the Windows implementation because
we should respect the Windows local settings folder. Another bug can be opened
on the Linux implementation. However I think the easiest way of fixing this
under Linux is to just relnote the administrator that he should set
browser.cache.directory in the global prefs (e.g. all.js) before deploying the
browser
OS: Linux → Windows 2000
*** Bug 128012 has been marked as a duplicate of this bug. ***
*** Bug 128979 has been marked as a duplicate of this bug. ***
how can the local administrator set the browser cache directory in all.js
without having different users' caches interfere with each other?

i'd like to set it to (say) /usr/tmp/<user>/mozcache
*** Bug 140481 has been marked as a duplicate of this bug. ***
adding dep from dup
Blocks: 31732
Pitfall on windows: In an environment with roaming profiles, the user profile
directory and the local application data directory may change between
sessions. So initializing the browser.cache.disk.parent_directory setting
to some explicit value pointing into the local application data directory 
and storing it in prefs.js would be the wrong.
The Cache is fundamentally different from preferences, address books and the
like: it is disposable.  I prefer to have it on some sort of /tmp /var/tmp or
other partition that indicates its temporary nature.
*** Bug 192470 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.8
Target Milestone: mozilla1.0.1 → ---
QA Contact: tever → benc
I've just read Bug 46490 from start to end, as well as this particular bug. Why,
oh why, is the location of the disk cache not supported as an environment
variable? I tried setting user.js with ..
user_pref("browser.cache.disk.parent_directory","%TEMP%"
**IF** it had worked (you all knew it wouldn't, didn't you?) it would have
allowed me to setup the cache in %TEMP%/Cache ... wherever that happened to be
pointing on the local machine, while still keeping user.js on a network server.
If an environment variable were supported, the local administrator could decide
where best to put it and users could roam freely over machines with different
configurations without having lowest-common-denominator performance for this
critical feature. 
> Why, oh why, is the location of the disk cache not supported as an environment
variable?

That's not an issue with the cache. The cache asks the prefs for
"browser.cache.disk.parent_directory" as an nsILocalFile object. That fails
because the prefs service does not expand environment variables in file prefs.

Rather than allowing somebody to specify the actual path to the Cache parent
dir, the pref could just be a boolean, "browser.cache.disk.local_temp" Then, you
could just make the location relative to NS_OS_TEMP_DIR. If this pref was set,
the cache could just get NS_OS_TEMP_DIR from directory service, and append from
there. You may be able to use nsIRelativeFilePref, if it's more convenient.
The correct reason (not to say this is how it was decided) is that some systems
have small and/or ram-based temp spaces.

We still have ugliness like "download manager puts files into cache". That makes
the cache size potentially problematic for the OS.
Summary: Disk cache directory should default be set to local computer directory → Disk cache directory should default to local directory
*** Bug 211124 has been marked as a duplicate of this bug. ***
*** Bug 89903 has been marked as a duplicate of this bug. ***
nominating:

Do we need separate bugs for UNIX (Linux+Mac) and Windows?

We also need to think about the behavior of the pref:

Mozilla's profiles do not contain an entry for the cache dir in all.js, so the
preference:

browser.cache.disk.parent_directory

is actually normally empty. When this happens, the value uses the default value.

When you open the prefs panel, the panel uses the same default value. (In fact
it populates the value on open, so even hitting cancel will set this value.

I don't know if the two situations are using the same code to generate the path,
but we need to know that, in order to fix this so it works in all situations.
Keywords: nsbeta1
Note: on Mac OS X, the standard location for chache is ~/Library/Caches. See bug
216204 how CMU implemented roaming profiles on OpenAFS, where the caches where
still stored locally.
*** Bug 225587 has been marked as a duplicate of this bug. ***
*** Bug 123080 has been marked as a duplicate of this bug. ***
I've created a new bug 239254 for Linux/UNIX NFS mounts. Bug 89903 mentions SMB
mounted home directories, but my impression is that these are pretty rare, most
users use roaming user profiles.
Assignee: gordon → darin
QA Contact: benc → cacheqa
Summary: Disk cache directory should default to local directory → Disk cache should use local directory (CSIDL_LOCAL_APPDATA)
Blocks: 239288
*** Bug 241579 has been marked as a duplicate of this bug. ***
*** Bug 246809 has been marked as a duplicate of this bug. ***
*** Bug 241579 has been marked as a duplicate of this bug. ***
Nominating for Fx1.0 for reasons mentioned already in comments. Most importantly
if this bug isn't fixed the could slow down logins for people who have their
profiles on the network or use Windows roaming features (not the 4.x roaming
features that I believe have been recently added to Seamonkey).
Flags: blocking-aviary1.0?
I have no time to work on this.  Helpwanted.
Severity: normal → enhancement
Keywords: helpwanted
Target Milestone: --- → Future
*** Bug 255646 has been marked as a duplicate of this bug. ***
*** Bug 245681 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0? → blocking-aviary1.0-
This is a real pain when running Firefox in terminal services. The browser is
extremely slow and unresponsive using a network cache location.

In the end I had to create a replacement firefox.exe to point the profile
locally, and store just the bookmarks on a network location.

Firefox should not expect files in a network file location to operate quickly.
In addition to the cache causing problems, the parent.lock file can cause the
browser to become unresponsive when shutting down and launching multiple
instances of a new browser.

I took a great deal of work to get Firefox working in terminal services. I am
certain that most other organizations wouldn't bother going through the hassle.

Thanks!
Trevor Fuson
University of Northern British Columbia
*** Bug 262836 has been marked as a duplicate of this bug. ***
*** Bug 262974 has been marked as a duplicate of this bug. ***
This bug (74085) was opened on 30 March 2001, more than 3 years ago.  It is 
easy to fix it, at least on Windows where it is clear what the correct 
locations are:

CSIDL_APPDATA\Mozilla\Firefox
CSIDL_LOCAL_APPDATA\Mozilla\Firefox

(see http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/shellcc/platform/Shell/reference/enums/csidl.asp)

which is normally equivalent to 

%USERPROFILE%\Application Data\Mozilla\Firefox
%USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox

Usage (plus code sample, look for "[C++]")

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/frlrfsystemenvironmentclassgetfolderpathtopic.asp

Constants used for GetFolderPath (SpecialFolder.*):

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpref/html/frlrfsystemenvironmentspecialfolderclasstopic.asp

Note that these locations can change between sesssions, so you can't determine 
their values at Firefox install time and save in the prefs file.  You need to 
determine their value on every Firefox startup.
Here is another method to accomplish the same thing using SHGetFolderPath and 
the CSIDL_* id's 

http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;310294&product=vcNET

instead of Environment::GetFolderPath with Environment::SpecialFolder::* as in 
the previous example.
Erlendur, this bug is much harder to fix than you are imagining; we know how to
get the local data paths, but it requires reworking a decent part of the gecko
code which handles profile locations.
*** Bug 260206 has been marked as a duplicate of this bug. ***
Benjamin, OK, fair enough, I'm not involved with the code so I can't tell.

However, given the time period (3+ years) this bug has been open and the 
rather negative response to a similar bug report (bug 260206) then I had to 
start somewhere.

I'm evaluating Firefox 1.0PR but I can't deploy it my network unless its cache 
is stored in a non-roaming application data folder.
Terminal Services / Roaming Profiles installation

The easiest way to bypass this problem is to compile a batch script (.bat file)
and replace the firefox.exe with the batch script.

Sample Batch Script:
start firefox2.exe -Profile "%USERPROFILE%\Local Settings\Application
Data\Mozilla\Firefox\profiles\default.xxx" -url "%1"

Note: firefox2.exe is the name of the original executable. You will need to find
a batch file compiler.

You will need to create a profile in the default user profile under local
settings.  You can also adjust the prefs.js in this location as well.

You will need to modify the registry in one location to specify an alternate
icon if Firefox is set as the default browser. This will be noticeable because
the start menu will show Firefox with an inappropriate icon. You may want to
adjust the registry permissions to deny modifying any keys you set so that
upgrades don’t alter your changes.

HKEY_LOCAL_MACHINE\SOFTWARE\Clients\StartMenuInternet\firefox.exe\DefaultIcon\

In addition you will need to create a shortcut for all users with the correct
icon in such places like the desktop, startmenu and quicklaunch bar locations.

Finally you will probably want to set a userpref in the prefs.js to place the
bookmarks on the users home drive.  Since you can't use environmental variables
in the prefs.js file to specify the correct UNC path, you will need to use a
mapped drive.

user_pref("browser.bookmarks.file", "H:\\TSProfile\\Application
Data\\Mozilla\\Firefox\\bookmarks.html");
I think that the default profile location should change from
CSIDL_APPDATA\Mozilla\Firefox to CSIDL_LOCAL_APPDATA\Mozilla\Firefox.
This would not require major reworking of the code.

It is crippling to have the profile under CSIDL_APPDATA for roaming users yet it
makes no difference where the profile is on the local drive for local users.

This way roaming users can still specify bookmarks and other settings to point
to network drive locations.  

In addition the code can then be changed incrementally to move individual files
back to CSIDL_APPDATA\Mozilla\Firefox on a case by case basis.  This greatly
reduces the complexity of the change and immediately fixes most of the problems.
Sorry, but that's no solution at all.  The settings should be correct by 
default for both home users and business users.  You should not force one 
class of user to go fiddling with settings just to make the application behave 
the way people expect it to out of the box.
What I proposed wasn't a solution to the complete problem. Since the problem has
been outstanding for 3+ years and no solution is in sight I would take a partial
fix over a complete fix.

It doesn't matter whether you are a home user or a business user, the settings
are incorrect as they are now.  My proposal don't negatively impact performance
for home users, or change the amount of fiddling a home user needs to do in
order to get firefox working as they expect out of the box.

It does fix the problem of business users not being able to even use Firefox
because of severe performance problems dealing with the cache and the
parent.lock files on network locations.

I think it is a terrible idea to move the entire profile into 
a non -roaming folder.
Requiring special configuration to avoid losing bookmarks is asking for trouble.

I know it sucks - believe me i know - but i reconfigure every user's profile to
put the cache in the the Local Settings area and leave the rest
We have 15,000 accounts, it's not practicle to hand configure each account.  At
least it is possible to properly configure the bookmarks in an automated
fashion, unlike the cache location.
There is a group policy setting that allows administrators to configure which 
folders are considered "local folder" within a profile. However, due to the 
mangled folder names, this setting won't work well as a temporary solution.

please note that there is a firefox preference that you can set to configure the
location of the 'Cache' folder.

if you are deploying firefox to a number of users, you might want to edit
firefox.js in defaults/pref to contain a line like this:

  pref("browser.cache.disk.parent_directory", "c:\some\dir");

then, firefox will store its cache under:

  c:\some\dir\Cache

this should help as a temporary fix until we patch the default behavior.
I can see privacy issues with that approach.

Would it not accept an environment variable?
Unfortunately moving the cache location in a terminal server would mean all
users  on a terminal server would point to the same cache directory.  This could
be several thousand different accounts in various load balancing senerios.

I imagine this would create problems with cache conflicts and unforseen security
risks since all users will have read and write access to the same directory.

In addition you can't specify environmental variables in the prefs file, so
there is no way to direct the cache location to a unique location that I am
aware of.



ok, that makes sense.  i should have thought of that problem :-/
I was one of the people who opened this bug 3 years ago. I'm delighted to see a
sudden surge in activity. Unfortunately, this last post takes us back to the
beginning again!!!!

>------- Additional Comments From fuson@unbc.ca  2004-10-05 15:03 PDT -------
>Unfortunately moving the cache location in a terminal server would mean all
>users  on a terminal server would point to the same cache directory.  This
>could be several thousand different accounts in various load balancing >senerios.

Yes, that's right. Simply pointing the cache isn't enough in a multi-user
networked environment.

>In addition you can't specify environmental variables in the prefs file, so
>there is no way to direct the cache location to a unique location that I am
>aware of.

... and that's the killer! We really want to point the cache at %temp% and let
the local machine resolve the environment user-by-user. Sadly, the people who
know say it isn't possible. Sigh....
I was one of the people who opened this bug 3 years ago. I'm delighted to see a
sudden surge in activity. Unfortunately, this last post takes us back to the
beginning again!

>------- Additional Comments From fuson@unbc.ca  2004-10-05 15:03 PDT -------
>Unfortunately moving the cache location in a terminal server would mean all
>users  on a terminal server would point to the same cache directory.  This
>could be several thousand different accounts in various load balancing >senerios.

Yes, that's right. Simply pointing the cache isn't enough in a multi-user
networked environment.

>In addition you can't specify environmental variables in the prefs file, so
>there is no way to direct the cache location to a unique location that I am
>aware of.

... and that's the killer! We really want to point the cache at %temp% and let
the local machine resolve the environment user-by-user. Sadly, the people who
know say it isn't possible. Sigh....

instead of tweaking with the preferences, another possible solution is to write 
a windows logout script that will delete the mozilla cache BEFORE moving the 
roaming profile anywhere. a simple dos batch file could do the job, and it's 
possible to enforce the logout script via group policy somehow (i cant remember 
exactly where, but it's easy to find out). i don't know how robust this 
solution is though, but it seems to be ok.

would be nice if somebody made a working example that could be posted here. 
unfortunately i dont have time to do it, but i could use such a script... :-)

zsolt
Clearing the cache may work for roaming profiles if the cache location is copied
locally instead of being redirected. If you are deleting the cache each time you
may want to look into just turning the cache off.

There is still a problem with redirected folders because the folder is stored on
a network drive. Both the cache and the parent.lock file need to be stored on a
fast filesystem.
(In reply to comment #64)
> instead of tweaking with the preferences, another possible solution is to write 
> a windows logout script that will delete the mozilla cache BEFORE moving the 
> roaming profile anywhere. a simple dos batch file could do the job, and it's 
> possible to enforce the logout script via group policy somehow (i cant remember 
> exactly where, but it's easy to find out). i don't know how robust this 
> solution is though, but it seems to be ok.

A logout script is not a reliable solution because the directory is not cleared
in case of system crash, so there is still privacy issues.
The cache directory have to be stored in a user-protected directory.
CSIDL_LOCAL_APPDATA is the Microsoft recommended directory.

The only workaround to a built-in solution is to write a login script that:
- locates the profiles directory
- for each profile:
   * change prefs.js to set browser.cache.disk.parent_directory to
CSIDL_LOCAL_APPDATA\Mozilla\[Application]\Profiles\[profile directory]\Cache

Question: how to deal with multiple profiles? Can they all share the same cache
directory?
*** Bug 264890 has been marked as a duplicate of this bug. ***
I think Jo Hermans summed it up perfectly in bug report Bug 264890 - except he
used figures quite lightly.  If you have a 50MB cache and 700 users (which we do
on our administrative network) thats 35Gig of cache thats being copied to and
from the Profile Network share.  As most users login in a period of about an
hour between 8:30 and 9:30 - this would put an awful strain on the network.  The
comments about setting the cache to 0 are rather silly - why sacrifice the
benefits of using a cache when this silly bug can be so easily fixed?  Im sure
this is a hold-up for many corporations who want to distribute Firefox to their
users.

Cheers
Ben Langridge 
*** Bug 266595 has been marked as a duplicate of this bug. ***
*** Bug 269470 has been marked as a duplicate of this bug. ***
Severity: enhancement → major
Status: NEW → ASSIGNED
Priority: P3 → --
Target Milestone: Future → mozilla1.8beta
*** Bug 269567 has been marked as a duplicate of this bug. ***
one nice thing about multiple profiles is being able to run multiple mozillas at
the same time, which means that you can crash say half your windows and keep
half of them uncrashed. you can't do that if you share cache directories,
mozilla will get upset. if you don't use that feature and can assure yourself
that your users will never use that feature, then you could ignore this
recommendation and risk the consequences :).
*** Bug 271214 has been marked as a duplicate of this bug. ***
How about this:

Instead of storing the cache objects directly in
browser.cache.disk.parent_directory, Firefox should use a subdirectory of it.
The name of the subdirectory should contain login name/profile name so cache
entries could be preserved between sessions, but different users could have
different subdirectories there.

Of course very strong check should be done on every browser startup, whether the
_user has exlusive permissions_ on that subdirectory.
Sorry, I forgot to write down the first half of the idea:

The rationale behind this would be to allow Comment #58 to actually work.
It'd would probably be pretty easy to create a Firefox 1.0 extension that sets
that pref according to the current userid, etc.  I was thinking of writing such
an extension if I ever find the time.
Would be such an extension capable to check every possible security issue
regarding to the cache directory? I mean Windows ACLs and UNIX permissions (not
to mention UNIX ACLs) to exclude other users and stuff to prevent UNIX symlink
attacks...
(In reply to comment #74)
> How about this:
> 
> Instead of storing the cache objects directly in
> browser.cache.disk.parent_directory, Firefox should use a subdirectory of it.
> The name of the subdirectory should contain login name/profile name so cache
> entries could be preserved between sessions, but different users could have
> different subdirectories there.

This is acceptable if %USERDOMAIN% and %USERNAME% are used, since username is
not unique in a multi-domain environment. A preferable format would be
%USERNAME%.%USERDOMAIN%. This is what Windows does, it appends the domain name
to the Windows profile name if a Windows profile of that name already exists.

I wouldn't like using the Firefox profile name very much, because we couldn't
set a default Firefox profile for all users then, it wouldn't be unique.  In
addition it would be difficult resolving Firefox profile name to a username if
there was a problem with the cache folder. Imagine having 1000 Firefox profiles
and you need to delete fusont's cache folder for some reason.

The security side would be somewhat sloppy since typically with Windows you keep
all of the users information in thier Windows Profile. Inherited permissions
through the Windows Profile can be audited easily, but if you deviate from the
recommended windows directories it can be difficult auditing permissions.
Shouldn't the Cache be stored in
CSIDL_LOCAL_APPDATA\Application Data\Mozilla [Firefox]\PROFILE NAME\Cache.

That would support multiple Windows users/domains and multiple Mozilla/Firefox
profiles.
Yes David, ideally the cache should be stored in CSIDL_LOCAL_APPDATA\Application
Data\Mozilla\Firefox\Profiles\<PROFILE NAME>\Cache.

Local Settings should contain the structure that is already in place in
Application Data, that way if other items need to be localized the directory
structure doesn't need to change in Local Settings.
So is Comment #74 a workaround? The current functionality is fine for custom
cache locations, just the default is incorrect.
It's more complicated than the defaults being incorrect.

The profile for each user should be stored in two different locations: 
permanent data (settings, bookmarks) in one location and temporary data (cache) 
in the other location.

Under Windows these would be:

CSIDL_APPDATA\Mozilla\Firefox
CSIDL_LOCAL_APPDATA\Mozilla\Firefox

which is normally equivalent to 

%USERPROFILE%\Application Data\Mozilla\Firefox
%USERPROFILE%\Local Settings\Application Data\Mozilla\Firefox

which is normally equivalent to 

C:\Documents and Settings\%USERNAME%\Application Data\Mozilla\Firefox
C:\Documents and Settings\%USERNAME%\Local Settings\Application 
Data\Mozilla\Firefox

When the user has a roaming profile then CSIDL_APPDATA (i.e., settings) is 
synchronised with the server but CSIDL_LOCAL_APPDATA (i.e., cache) is kept 
local and off the network.  This keeps network traffic to a minimum during 
login/logoff, and is necessary in my opinion for Firefox to be a viable option 
in large corporate environments (out of the box without cumbersome workarounds).
Obviously the defaults shouldn't be static; they need to be based on the logic
in Comment #82. Still a default though.

This should be easy to implement - when Firefox is started it should lookup
CSIDL_LOCAL_APPDATA and uses the Cache there (unless browser.cache.directory is
used to override it).
Or should browser.cache.directory be set to a subfolder of CSIDL_LOCAL_APPDATA
when the profile is created?
(In reply to comment #83)
> Obviously the defaults shouldn't be static; they need to be based on the logic
> in Comment #82. Still a default though.
> 
> This should be easy to implement - when Firefox is started it should lookup
> CSIDL_LOCAL_APPDATA and uses the Cache there (unless browser.cache.directory is
> used to override it).
> Or should browser.cache.directory be set to a subfolder of CSIDL_LOCAL_APPDATA
> when the profile is created?

David, you are asking a good question.

browser.cache.directory MUST NOT be set at profile creation time, and the cache
location MUST be always computed at runtime, as it may change from one computer
to the other (%USERPROFILE% may not be the same location on every computer where
a profile is used).
If the user decides to override the location by setting browser.cache.directory,
it is his choice, which may not be secure or portable from one machine to the other.
I was going to say maybe browser.cache.directory should be set to
CSIDL_LOCAL_APPDATA if it isn't already set. This would then be persistent.

However Olivier's quite right; it's possible that CSIDL_LOCAL_APPDATA will be
different on different machines (especially different versions of Windows).
Therefore IMO browser.cache.directory, unless set, should be looked up every
time Mozilla/Firefox starts.

This would also be a problem for browser.download.defaultFolder and possibly
browser.download.lastDir. But that's a separate bug.
(In reply to comment #85)
>
> However Olivier's quite right; it's possible that CSIDL_LOCAL_APPDATA will be
> different on different machines (especially different versions of Windows).

The value of CSIDL_LOCAL_APPDATA can also change between logins on the same 
machine.  The logic at runtime should be approx. as follows:

    Resolve CSIDL_APPDATA (= x)
    Locate profile in x\Mozilla\Firefox (and/or subdirs)
    Process profile settings
        If browser.cache.directory is set, use that location
        If not: Resolve CSIDL_LOCAL_APPDATA (= y)
                Locate cache in y\Mozilla\Firefox\Cache

(Using a sub-folder for the cache allows of course for other temp. data to be 
stored under CSIDL_LOCAL_APPDATA\Mozilla\Firefox)

On Linux these locations I guess would be $HOME/.firefox (perm. data) and 
$TEMP/firefox/$USERNAME (temp. data)?  MacOS?

If no profile exists it should be created and the cache as well (if the cache 
exists but not the profile, then I guess the cache should be cleared).

> This would also be a problem for browser.download.defaultFolder and possibly
> browser.download.lastDir. But that's a separate bug.

The default folder for downloads is the desktop under Windows?  This can be 
determined by resolving CSIDL_DESKTOPDIRECTORY as far as I know, so unless the 
user specifies a different location in his/her profile settings then this 
location should be resolved at runtime.
(In reply to comment #79)
> Shouldn't the Cache be stored in
> CSIDL_LOCAL_APPDATA\Application Data\Mozilla [Firefox]\PROFILE NAME\Cache.
> That would support multiple Windows users/domains and multiple Mozilla/Firefox
> profiles.

That's not necessary since the value of CSIDL_LOCAL_APPDATA is different for 
each user, the default value is C:\Documents and Settings\<username>\Local 
Settings\Application Data, ... unless you want to support multiple profiles for 
a single user?
I would just like to remind everyone that %USERNAME% is not unique in a Windows
Domain and that using something like "C:\Documents and Settings\%USERNAME%\Local
Settings\Application Data\" is dangerous.
(In reply to comment #88)
> I would just like to remind everyone that %USERNAME% is not unique in a Windows
> Domain and that using something like "C:\Documents and Settings\%USERNAME%\Local
> Settings\Application Data\" is dangerous.

In fact for a clean solution probably
- both CSIDL_LOCAL_APPDATA and CSIDL_APPDATA (others?) need to be determined at 
  run time
- Mozilla needs the ability to specify directories relative to those in its
  configuration settings

If, instead, you just decide to put the cache directory somwehere below
CSIDL_LOCAL_APPDATA unless set explicitly, you end up with a default setting
that cannot be expressed (at least not precisely) by an explict setting.
> you end up with a default setting
> that cannot be expressed (at least not precisely) by an explict setting.

let me note that that's alraedy what happens today, since you can't specify a
profile-relative cache directory explicitly. there does not seem any need for
that either.
(In reply to comment #89)
>
> - both CSIDL_LOCAL_APPDATA and CSIDL_APPDATA (others?) need to be
>   determined at run time

Also CSIDL_DESKTOPDIRECTORY for the default download folder (see bug 272007).
(In reply to comment #87)
> That's not necessary since the value of CSIDL_LOCAL_APPDATA is different for 
> each user, the default value is C:\Documents and Settings\<username>\Local 
> Settings\Application Data, ... unless you want to support multiple profiles for 
> a single user?

Mozilla and Firefox currently support this, so the new cache location would have
to also.

(In reply to comment #88)
> I would just like to remind everyone that %USERNAME% is not unique in a Windows
> Domain and that using something like "C:\Documents and Settings\%USERNAME%\Local
> Settings\Application Data\" is dangerous.

I think this path was used as an example of most installations,
CSIDL_LOCAL_APPDATA would be used for the correct location so this wouldn't be a
problem.
No new insights, just an attempt to boost the status of this bug.

I work at a school and have quite a few students asking me to install FireFox.
However, the one major bug that is holding me back is this one. I have one user
who has FireFox installed in his (roaming) profile folder and it causes no end
of problems, because the cache fills up and then it takes ages to log off. I
don't want to have to fiddle around with scripts and changing default settings -
it should 'Just Work', and Windows already has the infrastructure to get it to
work quite easily, in the form of the 'Local Settings' folder. Until this is
fixed, I am not going to install FireFox, and if you look into the other
comments on this bug, and also put the bug number into Google with 'firefox',
you'll see many other people who are saying the same thing.

The solution may be uncertain for Linux and the Mac, but it's simple for
Windows, and as far as I can tell it's not so much of an issue for Linux/Mac
anyway. Please, just fix Windows for the moment, and worry about the others later.
This is marked as a Windows bug after all.
*** Bug 279248 has been marked as a duplicate of this bug. ***
(In reply to comment #94)
> The solution may be uncertain for Linux and the Mac, but it's simple for
> Windows, and as far as I can tell it's not so much of an issue for Linux/Mac
> anyway. 
For the others see bug 239288.

Summary: Disk cache should use local directory (CSIDL_LOCAL_APPDATA) → [Win] Disk cache should use local directory (CSIDL_LOCAL_APPDATA)
Come on. Is it just because this affects large microsoft based networks that 
it isn't being fixed? Perhaps Firefox has never been tested on such an 
installation? Either way, you HAVE to realise that this is a complete show 
stopper for a rollout on most company networks. Even one user has a terrible 
experience logging on and off. 100 users would be a nightmare. 1000 a disaster.
Strictly speaking this bug is one of three major show stoppers for a rollout 
on large corporate (Windows) networks.  The other two are (A) the lack of .MSI 
setup packages and support for Group Policy installations, and (B) the lack of 
support for management via Group Policy.
(In reply to comment #99)
> Strictly speaking this bug is one of three major show stoppers for a rollout 
> on large corporate (Windows) networks.  The other two are (A) the lack 
of .MSI 
> setup packages and support for Group Policy installations, and (B) the lack 
of 
> support for management via Group Policy.

Actually, I think that the MSI deployment problem is going to be solved on the 
next release. As far as I am aware, the nightly builds are auto-generating .msi 
files as well as a .exe installer. See bug 231062.
OK, great.  Then the list is down to solving this bug and providing a method 
for enterprise management of Firefox, preferably via Group Policies (GP).

GP support has been hacked for Firefox, see, e.g., FirefoxADM at 
http://spaces.msn.com/members/in-cider/ but the general approach has the 
drawback that GP using the appropriate Administrative Template will create 
registry settings that have to be converted into a prefs.js file.  In 
FirefoxADM this is done by using a VBScript at logon that does a search-and-
replace on all prefs.js files!

This bug deals specifically with the location of the cache, but at a more 
general level it deals with where data and settings should be located.  To 
properly support GP management, perhaps some or all of the settings currently 
in prefs.js should be located in the registry.
Please open another bug about group policies, or cc me on an existing bug.
Instead of generic "configure with the registry" questions, it would be very
useful to have specific settings that you wish to change using the registry.
(In reply to comment #102)
> Please open another bug about group policies, or cc me on an existing bug.
> Instead of generic "configure with the registry" questions, it would be very
> useful to have specific settings that you wish to change using the registry.

Please see bug 267888 opened on 2004-11-05.  The discussion there, FirefoxADM 
and IE settings that are configurable via GP are a good starting point.

Getting back to this bug:  The "why?", "if?" and "how?" have been resolved.  
It's a must for enterprise deployment and the solution is clear (see discussion 
above).  The only thing remaining is "when?"...  I'm not the only enterprise IT 
manager waiting for a resoluton.
I intend to fix this bug for Firefox 1.1 / Mozilla 1.8.  However, I am not sure
that I will have time to incorporate any sort of cache migration solution.  I am
also concerned about the overhead of deleting the cache from the old location. 
What I may do is provide a configuration option that network admins can enable
in the copy of Firefox that they deploy.
I guess that would be fine, so long as it's the default on *new* installs. The 
configuration option would be helpful to get rid of caches that are still in 
the 'old' area.
As yet another administrator for whom this is the biggest barrier to corporate
rolling out of Firefox, I agree that migrating an existing cache is *not*
important. All I want is the cache not to be "roamed" when this gets changed
i.e. by virtue of being stored in "Local Settings". (The history, cookies, etc.
should still be in "Application Data" and consequently get roamed).

Please let us know when these changes are in a test build as I'd like to get
testing!
I was pressured to roll-out Firefox in my organization by students, and then by 
co-workers, and finally forced to by supervisors.
We use roaming profiles for students, and the network infrastructure is having 
some serious issues dealing with ~500 users profiles which now are dumping 
useless Firefox cache information at every logon.

In a normal business environment this may be liveable, you know when it's going 
to get stressed, but here we have students going to different classes at 
different times of the day, so the excessive load varies all of the time.

A simple centralized fix was necessary, so I adjusted domain-wide group policy:
"User Configuration\Administrative Templates\System\Login/Logoff\Exclude 
directories in roaming profile"
Added "Application Data\Mozilla" to this list.

Incredibly crude -- ala "What Profile" -- but considering that it generates a 
random name for profile directory, that you cannot use wildcards for the 
exclusion list in gp (That I have found), and there are issues if you just 
delete "Application Data\Mozilla\Firefox\Profiles", it is something that must 
be done for now.

Immediate Server and Network Health > Minor Inconvience of users using "The 
Alternative Browser"

It also concerns me that this specific "Bug" is now nearing 4 years of age.
I wish the excluded folder gp setting worked for redirected folders,
unfortunately when you redirect a folder all of the subfolders are forcibly
redirected as well.

The only way to fix the problem then is to use the -profile command line switch
which gets real messy.

*** Bug 285336 has been marked as a duplicate of this bug. ***
*** Bug 285561 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2
*** Bug 286245 has been marked as a duplicate of this bug. ***
Priority: -- → P1
*** Bug 287113 has been marked as a duplicate of this bug. ***
This bug was opened 4 years ago today.

Fixing this bug (cache should use local directory, 4 years), bug #272007 
(default download folder should not be set at profile creation time, 4 months), 
bug #264889 (Firefox MSI packages, 1+ year), bug #267888 (Windows Group 
Policies support, 5 months) and the installer/updater (see e.g. bug #263595, 
e.g. comments 14, 15 and 20, 6 months) would help tremendously in penetrating 
the corporate world.

Corporate adoption is all about manageability.
Blocks: 216204
Flags: blocking-aviary1.1? → blocking-aviary1.1+
There's no way I can deploy firefox on my LAN because of the location of the
cache. I wish that bug had been corrected years ago.

Profiles are submitted to quotas, as it stands to reason (while local caches are
not) and that leads to the logoff process hanging and users being prompted to
prune their profile data (most users don't care and force-reboot): an extremely
efficient deterrent.

-- 

Bernard Bou
46106 Figeac
FRANCE

bbou@users.sourceforge.net
Blocks: 290399
This bug has been fixed now with the patch for bug 291033.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Depends on: 291033
Resolution: --- → FIXED
Well, noone else seems to be saying it, but if this bug really is fixed, 
congratulations and thank you very much!

Looking forward to the next FireFox release!
is there any chance to include this Feature in 1.0.4?
> is there any chance to include this Feature in 1.0.4?

No, but you could fairly easily develop a Firefox extension (or even a simple JS
component) that could be included in Firefox 1.0.x to achieve nearly the same
effect.

To do that, just create a JS component that sets the
browser.cache.disk.parent_directory pref based on environment variables, which
can be read via nsIEnvironment.
Why do people complain, such as in comment #114, that they can't deploy Firefox
in a LAN because of this bug? they just need to create specially formulated
user.js in the program directory then specify the local directory in a per-user
user.js when creating each user's profile. I've been doing this with Mozilla on
Windows for the past 3 years (see http://thegoldenear.org/tweak/). Here's how:


:f

::  +-----------------------------------------------------------------------------+

::  Prepare so that cache location can be specified for new (US) profiles

::  +-----------------------------------------------------------------------------+



echo.

echo Copy over the USER.JS configuration...

copy /Y "configs\user-(cache).js"
"%PROGRAMFILES%\mozilla\defaults\profile\US\user.js"



echo.

echo Making the USER.JS file read/writable...

attrib -r "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js"




:u

::  +-----------------------------------------------------------------------------+

::  Backup, delete, create new profile for/called %USERNAME%

::  Set cache to E:\%USERNAME%\Mozilla if 'F' has been run

::  +-----------------------------------------------------------------------------+



echo Delete any existing backups of Mozilla profiles...

:: if exist "%APPDATA%\Mozilla-old-profiles" rd /S /Q
"%APPDATA%\Mozilla-old-profiles"

if exist "%APPDATA%\Mozilla\Mozilla-old-profiles" rd /S /Q
"%APPDATA%\Mozilla\Mozilla-old-profiles"

echo.



echo Backup any existing Mozilla profiles...

:: this also removes any existing registry.dat which contains info about
existing profiles 

:: which would confuse things, presenting the option to load another profile
that wouldn't exist

:: if exist "%APPDATA%\Mozilla" ren "%APPDATA%\Mozilla" "Mozilla-old-profiles"

if exist "%APPDATA%\Mozilla\Profiles" ren "%APPDATA%\Mozilla\Profiles"
"Mozilla-old-profiles"

if exist "%APPDATA%\Mozilla\registry.dat" del "%APPDATA%\Mozilla\registry.dat"

echo.



:: The following 2 sections within 'if exist's require write access to
%PROGRAMFILES%\Mozilla... but if that isn't

:: available they'll just fail and the cache setting won't be automatically made



:: If a pre-configured USER.JS exists, edit its cache location for this
particular user

if exist "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js" (

  rem Make a backup of the master user.js file that we can restore later...

  copy "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js" "%TEMP%\user-js-bak"

  echo.



  echo Remove the comments from the master user.js file...

  rem Our user.js has its lines commented out, incase its used accidentally as
its cache setting wouldn't work

  rem with the PUT_USER_TEMP_LOCATION_HERE in instead of an actual TEMP location

  perl -pi.bak -e "s/\/\/\;//gi"
"%PROGRAMFILES%\mozilla\defaults\profile\US\user.js"

  echo.



   echo Copy user.js to %TEMP% as a temporary workaround for a bug when using
Perl to set cache...

   copy "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js" "%TEMP%\user.js"

   echo.



  echo Insert %USERNAME%'s cache location into the master user.js file,
currently in %TEMP%...

  perl -pi.bak -e "s/PUT_USER_TEMP_LOCATION_HERE/E:\\\\$ENV{USERNAME}/gi"
"%TEMP%\user.js"

  echo.



   echo Copy user.js back from %TEMP% to the Mozilla program directory...

   copy "%TEMP%\user.js" "%PROGRAMFILES%\mozilla\defaults\profile\US\"

   echo.



   echo Delete the temporary user.js in %TEMP%...

   del "%TEMP%\user.js" 

   echo.



  rem The above is a workaround for a problem using Perl. see the documentation
for details



  rem type "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js" | sed
"s/PUT_USER_TEMP_LOCATION_HERE/%TEMP%/" >
"%PROGRAMFILES%\mozilla\defaults\profile\US\new-user.js"



  echo Tidy up by deleting Perl's backup...

  del "%TEMP%\user.js.bak"

  echo.



  echo Now the master user.js file is personalised for %USERNAME%

  echo and ready to be copied to %USERNAME%'s Mozilla profile...

  echo.

  )



echo Create new Mozilla profile called %USERNAME% for %USERNAME%...

:: if bug 97180 results in the ability to create non salted profiles then this
Mozilla profile name won't be a safe choice

"%PROGRAMFILES%\mozilla\Mozilla" -nosplash -CreateProfile %USERNAME%

echo.



:: If a pre-configured master user.js exists, restore to the original condition,
having just personalised the master.

if exist "%PROGRAMFILES%\mozilla\defaults\profile\US\user.js" (

  if exist "%TEMP%\user-js-bak" (

    echo Restore original pre-configured user.js so it can be used again for
others...

    copy /Y "%TEMP%\user-js-bak"
"%PROGRAMFILES%\mozilla\defaults\profile\US\user.js"

    echo.



    echo Tidy up by deleting the temporarily backed-up user.js...

    del "%TEMP%\user-js-bak"

    echo.

    ) else (

      echo ERROR: the backup of user.js in 

      echo %TEMP%\user-js-bak

      echo doesn't exist for us to restore!

      echo.

      echo %PROGRAMFILES%\mozilla\defaults\profile\US\user.js 

      echo has not been restored, possibly after it has been edited for

      echo %USERNAME%, leaving it in an uncertain condition.

      echo You should run %NAME%'s option to 'prepare so that a 

      echo cache location can be specified...' again.

      echo.

      )

  )
(In reply to comment #119)
> Why do people complain, such as in comment #114, that they can't deploy Firefox
> in a LAN because of this bug? they just need to create specially formulated
> user.js in the program directory then specify the local directory in a per-user
> user.js when creating each user's profile. I've been doing this with Mozilla on
> Windows for the past 3 years (see http://thegoldenear.org/tweak/). Here's how:

Your code is unsafe in terminal services environment situations because you
modify a file in a non-unique location for all users. When I deploy a new silo
server in our terminal services environment we could get up to 100 user logging
in and running firefox simultaneously at nearly the same time. This would cause
serious problems with multiple copies of your script running for each user.

If your script is only run as admin then I don't see how it is at all useful
unless you a running in a small environment with just a few users.
I can only stand up for my script working in the environment it was written for,
and in that it works fine, of users who number in the tens. I have no experience
of terminal services environments. However, I think perhaps you misunderstand -
I use it when configuring a user account, before the user gets to use it, so its
not used in an environment where it would be called multiple times per second as
you describe. Once user.js is configured it doesn't need to be reconfigured
again. but maybe this just make example of my lack of understandign of terminal
services.
*** Bug 303518 has been marked as a duplicate of this bug. ***
*** Bug 311100 has been marked as a duplicate of this bug. ***
*** Bug 316848 has been marked as a duplicate of this bug. ***
*** Bug 328595 has been marked as a duplicate of this bug. ***
*** Bug 358332 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.