My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 14545: Cache dir needs to be under ~/Library/Caches
20 people starred this issue and may be notified of changes. Back to list
Status:  Verified
Owner:  mark@chromium.org
Closed:  Oct 2009
Cc:  j...@chromium.org
M-4

Restricted
  • Only users with EditIssue permission may comment.


Sign in to add a comment
 
Reported by wout.mer...@gmail.com, Jun 18, 2009
Chrome Version       : 3.0.189.0
URLs (if applicable) :
OS version               : 10.5.8
Behavior in Safari 3.x/4.x (if applicable): Stores cache files in ~/Library/Caches/com.apple.safari
Behavior in Firefox 3.x (if applicable): not sure
Behavior in Chrome for Windows: not sure

What steps will reproduce the problem?
1. Run Chromium

What is the expected result?
2. Cache will be in ~/Library/Caches/com.google.chrome


What happens instead?
2. Cache is in ~/Library/Application Support/Google/Chrome/Default/Cache

Putting cache files under a predictable location for all applications makes it easy to exclude the 
cache from backups etc.
Jul 2, 2009
#1 mikesm...@chromium.org
(No comment was entered for this change.)
Labels: Mstone-MacBeta
Jul 8, 2009
#2 mikesm...@chromium.org
(No comment was entered for this change.)
Status: Assigned
Owner: j...@chromium.org
Jul 30, 2009
#3 j...@chromium.org
(No comment was entered for this change.)
Labels: Area-BrowserUI
Aug 16, 2009
#4 aka...@gmail.com
I'm looking into working on Chrome (on Mac/Linux) and this seems like a good place 
to start.

From digging around, it looks like what is needed is to add an OSX-specific clause to 
the chrome::DIR_USER_CACHE case in PathProvider() in chrome_paths.cc, and 
possibly add OSX-specific #ifdefs for kCacheDirname and kMediaCacheDirname in 
chrome_constants.cc.

Actually, it looks like I already have ~/Library/Caches/com.google.Chrome, but all it 
contains is a fairly old (June 13) empty Cache.db file.  Is this from an earlier build or 
something?  Or perhaps it is something autogenerated.

What do we want the directories to look like?  I'm guessing for Chromium:

~/Library/Caches/Chromium/{Cache,MediaCache}

and for Chrome:

~/Library/Caches/com.google.Chrome/{Cache,MediaCache}

What do you think?
Aug 17, 2009
#5 j...@chromium.org
It isn't clear we want to change this, since there are complications (e.g. where does the incognito mode cache 
go?).  In addition, branding issues (Chromium vs "Google Chrome") will make this a little tricky for an external 
contributor to fix.
I will follow up in email.

Aug 17, 2009
#6 j...@chromium.org
+cc mark since I believe he expressed opinions on this in email in the past

Cc: m...@chromium.org
Aug 17, 2009
#7 mark@chromium.org
This might actually be a good first bug for a 20%er.

The cache directory should move so that it has the same name that we currently use 
for the profile directory, except in ~/Library/Caches instead of ~/Library/Application 
Support.

For example, a cache directory currently in ~/Library/Application 
Support/Google/Chrome/Default/Cache should move to 
~/Library/Caches/Google/Chrome/Default.  A cache directory currently in 
~/Library/Application Support/Chromium/Default/Cache should move to 
~/Library/Caches/Chromium/Default.

Optionally, if a Cache directory is found within the profile, we can continue to use 
that instead of the new location in ~/Library/Caches.

If the profile is outside of ~/Library/Application Support, the cache directory should 
remain within the profile by default.  This enables profile portability.  So does the bit 
about leaving the cache in the profile if it's already found there.

This change shouldn't be terribly difficult to achieve.  The cache directory can be 
redirected by starting at chrome::PathProvider in chrome/common/chrome_paths.cc 
and returning the value we want for chrome::DIR_USER_CACHE.  Linux presently does 
this.  See chrome::GetUserCacheDirectory chrome/common/chrome_paths_linux.cc.

(Linux is apparently not smart enough to use a different cache for each profile.  We 
are smart enough.  We will do better.)

That said, this is on the punch list for MacBeta.  While it's a decent first bug for a 
20%er, if a 20%er wants to take it on I'd strongly suggest starting on it now.
Aug 18, 2009
#8 aka...@gmail.com
> (Linux is apparently not smart enough to use a different cache for each profile.  We 
are smart enough.  We will do better.)

I have a CL that seems to work, and I'll send out a patch probably tomorrow or so.  
However, from digging around it seems that there is no easy way to get the profile 
name to tack on the end of the cache directory.  There is a 
GetProfileNameFromFolderName(), but it seems that it is Windows-centric, since it 
scans the folder name for "User Data", and partially broken ( see 
https://code.google.com/p/chromium/issues/detail?id=5070 ).

We should probably open up a new issue for a more robust way of getting/keeping 
track of the profile name and then after that we can use that to fix the cache paths 
for Linux/OS X.  What do you think?
Aug 18, 2009
#9 mark@chromium.org
You don't get the profile name to tack on to ~/Library/Caches directly.  You get the 
entire profile path, check for ~/Library/Application Support, and if it's present, chop off 
~/Library/Application Support to get the portion that can be added to ~/Library/Caches.

(Of course, you ask the system for these names, you don't hard-code them.)
Aug 21, 2009
#11 j...@chromium.org
Switching Owner/cc since mark is taking over review of CL.

Owner: m...@chromium.org
Cc: -m...@chromium.org j...@chromium.org
Sep 1, 2009
#12 pinkerton@chromium.org
(No comment was entered for this change.)
Labels: -Area-Misc
Sep 2, 2009
#13 j...@chromium.org
This is a release blocker for Mac Beta.
Labels: ReleaseBlock-Beta
Sep 2, 2009
#14 j...@chromium.org
We are deprecating the MacBeta milestone in favor of ReleaseBlock-Beta and 
a milestone.
Labels: Mstone-4
Sep 2, 2009
#15 j...@chromium.org
We are deprecating the MacBeta milestone in favor of ReleaseBlock-Beta and 
a milestone.
Sep 28, 2009
#16 j...@chromium.org
(No comment was entered for this change.)
Labels: -Area-BrowserUI Area-BrowserBackend
Oct 2, 2009
#17 rohitrao@chromium.org
 Issue 23619  has been merged into this issue.
Oct 2, 2009
#18 mark@chromium.org
r26387
Status: Fixed
Oct 2, 2009
#19 srikan...@chromium.org
verified fixed.

Platform:
  Hostname: Macintosh-0023dfded9ed.local
  Mac OS X Version 10.5.8 (Build 9L31a)
  Processor: 4 Intel 2.66 GHz
  RAM: 2048 MB

Chrome:
  Chrome version: 4.0.221.0  <<<Release/Debug>>>
  QuickTime Player: 7.6.4
  QuickTime PlayerX: <unknown>
  Flash Player: 10.0.32

Status: Verified
Dec 18, 2009
#20 mal.chromium@gmail.com
(No comment was entered for this change.)
Labels: -Area-BrowserBackend Area-Internals
Mar 5, 2010
#21 raul.mor...@gmail.com
I still get this issue. I am using Chromium 5.0.345.0 (40638) under Snow Leopard 10.6.2
Mar 5, 2010
#22 aka...@gmail.com
Have you been using Chrome since before this issue was fixed?  Existing cache 
directories were left alone on purpose.
Mar 5, 2010
#23 raul.mor...@gmail.com
Yes, I think you are right, I used Chrome before this issuse  was fixed, so this must by the problem. Thank you.
Mar 8, 2010
#24 maurer1...@gmail.com
Now that the caches are in the original place, how can they be moved back?  I tried quitting Chrome 
and deleting them but Chrome created a new set in the same location.
Oct 11, 2012
#25 bugdro...@chromium.org
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.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#26 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Mstone-4 -Area-Internals M-4 Cr-Internals
Mar 13, 2013
#27 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Sign in to add a comment

Powered by Google Project Hosting