New issue
Advanced search Search tips

Issue 6688 link

Starred by 9 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Feb 2009
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

  • Only users with Commit permission may comment.

Sign in to add a comment

Allow the user to set the disk cache location independently of the profile

Reported by, Jan 20 2009

Issue description

Chrome Version       :
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

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?

Please provide any additional information below. Attach a screenshot if 
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 :)


Comment 1 Deleted

Comment 2 by, Jan 21 2009

Uploaded proposed changes.
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 

Comment 4 by, 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 

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.


Comment 5 Deleted

Comment 6 Deleted

Comment 7 Deleted

Comment 8 Deleted

Comment 9 Deleted

Comment 10 Deleted

Comment 11 Deleted

Comment 12 Deleted

Comment 13 Deleted

Comment 14 Deleted

Comment 15 Deleted

Comment 16 Deleted

Comment 17 Deleted

Comment 18 Deleted

Comment 19 Deleted

Comment 20 Deleted

Comment 21 Deleted

Comment 22 Deleted

Comment 23 Deleted

Comment 24 Deleted

Comment 25 Deleted

Comment 26 Deleted

Comment 27 Deleted

Comment 28 Deleted

Comment 29 Deleted

Comment 30 Deleted

Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

Comment 35 Deleted

Comment 36 Deleted

Comment 37 Deleted

Comment 38 Deleted

Comment 39 Deleted

Comment 40 Deleted

Comment 41 Deleted

Comment 42 Deleted

Comment 43 Deleted

Comment 44 by, Jan 24 2009

Labels: -Type-Bug Type-Feature
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. 

Comment 45 by, 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. :)

Status: Untriaged
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.

Comment 47 by, 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.

Comment 48 by, 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 :)


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.

Labels: -Area-Misc Area-BrowserBackend
Labels: -Pri-2 Pri-3 Mstone-X
Status: Available
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.
“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.)

Comment 53 by, 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 :)

The following revision refers to this bug: 

r9375 | | 2009-02-06 17:58:42 -0800 (Fri, 06 Feb 2009) | 14 lines
Changed paths:

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

In this implementation, the supplied directory name must should not
contain spaces.

BUG= 6688 

submitted by bekkra.
original code review


Status: Fixed

Comment 56 by Deleted ...@, Feb 18 2009

Labels: -Area-BrowserBackend Area-Internals
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 

Comment 59 by, Feb 15 2011

#58, I have the same problem. I solved it using junction points (symbolic links à la Windows):
Project Member

Comment 60 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 61 by, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment