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.

Marking NEW.

Cache pref work is scheduled for 0.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

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.

I think there are still too many issues to work out before the 0.9.2 code freeze. Moving to 0.9.3.

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.

Fwiw, see bug 89903 (Slow Page Load With Cache on Remote Drive).

marking nsenterprise-; will be reevaluated for nsenterprise in future release.

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

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)

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.

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

*** 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

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

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.

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

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.

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

I have no time to work on this. Helpwanted.

*** Bug 255646 has been marked as a duplicate of this bug. ***

*** Bug 245681 has been marked as a duplicate of this bug. ***

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

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

The following links may be useful: http://shrinkster.com/2el http://shrinkster.com/2ek http://shrinkster.com/2en

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

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

*** Bug 286245 has been marked as a duplicate of this bug. ***

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

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

This bug has been fixed now with the patch for bug 291033.

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