Allow the user to set the disk cache location independently of the profile
Reported by bek...@gmail.com, Jan 20 2009
Chrome Version : 220.127.116.11 URLs (if applicable) : Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 3: n/a Firefox 3: n/a IE 7: n/a What steps will reproduce the problem? 1. The browser allows no user-configurable location for the disk cache 2. 3. What is the expected result? After the addition of this functionality, users should be able to instruct the browser to use the disk cache at a specific location, and disregard any current cache. What happens instead? n/a Please provide any additional information below. Attach a screenshot if possible. For some users, using the account profile to store the kind of data like the browser's disk cache is unfavorable, or even forbidden. The data type is also very different from the type that the user's settings represent. Moving the cache off-profile allows for better separation of the browser's data from the user's data. The solution that I have tested has a trivial implementation, but it allows only the cache to be moved. Cookies and other history data is not moved. The proposed change has applied well for some time and the implementation holds for the current tests. I have no idea if we should - or could - write proper tests for the change itself, but I guess it's possible :) bekkra //
Jan 21 2009,
Uploaded proposed changes. http://codereview.chromium.org/18630
Jan 22 2009,
Why do you want to move only the cache data and not the cookies or history?. All the user-related data can be moved just by specifying a different profile directory with --user-data-dir=my_folder.
Jan 23 2009,
I am thinking of the general issue of separation between data types. Separation of data types based on source is a very new idea in the Windows world ( remember when app apps stored everything in their installation directory ? ) while the Unix-like systems at least separated "user owned" data from "system owned", since they had been built for multi-user operation from the ground. Our thinking could be to separate the application data depending on several properties. The cache is user-specific, since it is created in the context of the user. Even though the user owns the files, she is not interested in the cache, but the *performance* that it provides. This makes the cache into *application* data, which very well may be viewed as "installation" specific. Windows has the "Local storage" idea for this. In contrast, the user's settings is typically something that should not change just because the user's files move around, so those need be in the "Roaming" profile. Cookies can initially be regarded as a for of cache, but further thinking highlights a major difference. Many cookies contain information to help the user in navigation (even log in), in which case the cookies are more like "preferences" or "history", rather than "cache". This calls for a cookie storage policy of "Roaming". Imagine now that the user has limited storage for personal files. Imagine further that the user has his personal files synchronized with a server. Browser caches take space. What if our user has 40 MB total storage allowed in her profile ? Easy, you say: move the entire browser profile ! But the "Local" storage is not important to save, as opposed to the "Roaming" storage, which contains data that defines the user's work points. Copying the cache to, say, a local place on the hardware allows the user's settings - and with them, the Chromium preferences - to be copied along between different installations, while saving the time to copy unimportant files. Even if most of the above apply to corporate users ( don't we use the Enterprise tag for this ? ) even home use is easier when the low priority data in the cache is moved off-profile. The profile can be backed up with no loss to the user, resulting in smaller backup archives that help performance ( less stolen time for comparisons, compression, encryption and copy ). I can see that the user may lose the cache (by accident, managed updates, or by moving to a different machine), but still have her preferences and site specific data synchronized (or backed up). So yes, my view is still that the cookies and the cache represent two very different kinds of data that we may use - or allow - different storage policies for. //
Jan 24 2009,
bug -> feature I don't oppose the idea of having the cache in another drive, this would speed things in some cases. In other cases there is more space on a different drive. However, my guess is that the right thing to do is to expose UI to change the location of the cache (like we do for the download dir) and keep a pointer in the profile for this location. I don't like the idea of being able to specify profile and cache separately on the command line.
Jan 24 2009,
I agree fully to the idea of using a "visible" configuration for the cache. There are two reasons for taking the road over the command line: The first is the obvious speed of implementation of the command line change. It is a low-risk, easily tested change with full return. Needless to say, I want this for myself because this lets me use the browser where its cache storage policy would otherwise stop me. The second is that a change in the GUI needs careful consideration, which means quite a few discussions, and in the implementation phase, much more error-prone changes. The changes require testing and a review process which is more elaborate than in the case of the command line switch. Given the nature of the change, it is more to regard as extra functionality, and I see that our resources are better spent on actual bugs than on adding infrequently used features. While I see that we can provide a "good enough" feature by the command line change to little effort, I can only see a GUI change as a "sometime in the future" addition. I would love to find acceptance for this new option in the "under the hood" tab, and I would be very pleased to work with it. In the meantime, though, having the functionality in place and accessible through the command line, gives that "good enough for the moment" feeling. :) //
Jan 27 2009,
I also believe that the right thing to do is to have an extra setting under the hood to change the default values for cache location and maximum size.
Jan 27 2009,
I love this idea! I'm using a ramdrive to put my firefox's cache in it. In some cases, like a heavy- load and full-of-flash site, it does help my fx speed-up a lot.
Jan 27 2009,
Well :) I'm happy to see the comments about the change, but do you (rvargas + cpu) really mean that this quick and miniature (after the latest review almost nil) change should never be done ... instead we should trust somebody to create the GUI change proposal ? I would like to see that decision, so that this feature can be closed and a new opened for the proposed GUI work. While I dislike your idea about this, I would still be happy to find acceptance for SOME method of providing the settings. I am ready for the GUI work too :) //
Jan 28 2009,
Everyone seems to be missing the bigger issue. A browser cache is transistory, transient, temporary. You don’t keep it forever, and in fact clear it out to free up space, cover your naughty tracks, etc. Cookies, settings, and such are things you want to keep. It makes sense to be able to separate them.
Jan 28 2009,
Jan 28 2009,
I don't really see the benefit to most users to set a different cache path (separate from user-data-dir). A command line switch is a reasonable alternative if it doesn't introduce code complexity. Adding UI to the options panel is a separate bug.
Jan 29 2009,
“I don't really see the benefit to most users to set a different cache path (separate from user-data-dir).” That’s probably because you have a drive big enough to store everything forever. Do you store your Documents and Settings on the same drive as Windows itself? If so, then you need to brush up on file organization, if not, then you should be able to see how it applies to this. (In fact, that Chrome insists on putting the application files in the user folder—for each user, thus wasting a lot of space—instead of putting them in a separate, central location is bad enough.)
Feb 5 2009,
I have uploaded a new change set, because I lost the cookie to the original one. The new set is a very minor change :) http://codereview.chromium.org/21094 //
Feb 8 2009,
The following revision refers to this bug: http://src.chromium.org/viewvc/chrome?view=rev&revision=9375 ------------------------------------------------------------------------ r9375 | firstname.lastname@example.org | 2009-02-06 17:58:42 -0800 (Fri, 06 Feb 2009) | 14 lines Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/AUTHORS?r1=9375&r2=9374 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profile.cc?r1=9375&r2=9374 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=9375&r2=9374 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=9375&r2=9374 Adds a command line switch to allow the user to specify the location of the disk cache, rather than in the profile directory. The command line switch overrides the cache location regardless the chosen profile. In this implementation, the supplied directory name must should not contain spaces. BUG= 6688 submitted by bekkra. original code review http://codereview.chromium.org/21094/show ------------------------------------------------------------------------
Feb 9 2009,
Feb 18 2009,
Dec 18 2009,
Feb 15 2011,
Command line flags are only a partial solution, as they only affect Chrome when run explicitly. However, as an example, clicking on a link in an email or other document will start the default browser using settings in the registry. Unless the end user tweaks registry entries like HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command the cache directory will be the default when chrome is started from a link. In my case my boot drive is an SSD, so I want the cache always to be on a different drive both for space considerations and to prolong drive life. In addition, I use Allway Sync to replicate my user directory to a backup location, and don't need to be replicating the cache. Until this can be made a true UI setting, please consider implementing it in the about:flags
Feb 15 2011,
#58, I have the same problem. I solved it using junction points (symbolic links à la Windows): http://en.wikipedia.org/wiki/NTFS_junction_point
Oct 12 2012,
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 10 2013,
Sign in to add a comment