+dconnelly who implemented the policy. Could you provide some input here?

"blob_storage" directory should probably be relocated as well

It looks like this policy has been implemented a long time ago and dconnelly hasn't visited the bug tracker for a long time.

I'll try to add contributors who might know if it's OK to move the cache folders in question.
We might want to centralize code for assembly of paths to cache directories, if that's possible (i.e. not every cache dir has its special case).

+jmadill
Would you know if the path to ShaderCache can be changed to be based off the kDiskCacheDir pref if it's non-empty, instead of being based on USER_DATA_DIR unconditionally? 

(e.g. like it's being done in [2])

[1] https://cs.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?l=2636&gs=cpp%253Aclass-ChromeContentBrowserClient%253A%253AGetShaderDiskCacheDirectory()%2540chromium%252F..%252F..%252Fchrome%252Fbrowser%252Fchrome_content_browser_client.cc%257Cdef&gsn=GetShaderDiskCacheDirectory&ct=xref_usages
[2] https://cs.chromium.org/chromium/src/chrome/browser/profiles/profile_impl.cc?l=1348&gs=cpp%253Aclass-ProfileImpl%253A%253AGetMediaCacheParameters(base%253A%253AFilePath%2B*%252C%2Bint%2B*)%2540chromium%252F..%252F..%252Fchrome%252Fbrowser%252Fprofiles%252Fprofile_impl.cc%257Cdef&gsn=GetMediaCacheParameters&ct=xref_usages

I assume "Local Storage" (and "Session Storage" too) should _not_ be treated as a cache, it should be treated similarly to cookies. This is data websites can store locally.
So I'd say that it's OK that Local Storage does not depend on the policy value.
Please protest if you disagree.

+dmurph
Daniel, would you know if it would make sense to change the path of the blob_storage directory[1] when the kDiskCacheDir pref is set? AFAIK blob_storage doesn't persist browser sessions (or does it?) so it could be regarded as a "cache".
Background: There's a command line flag and a enterprise policy to move caches to another directory, and blob_storage is one of the directories which don't get moved. We are wondering if it should be moved too or not.

[1] https://cs.chromium.org/chromium/src/content/browser/blob_storage/chrome_blob_storage_context.cc?rcl=cd79e17ec56bba732e6295877c7c9c896950271d&l=97

I'm actually not entirely sure. Is it possible to add a test that covers the configuration with the disk cache moved?

Hm - I just use the storage partition directory (same place we store stuff like IndexedDB or localstorage). I guess it's true this is just cache, and it shouldn't be hard to move that directory.

@pmarko:  Hello!  Regarding Comment 5, an argument or question can be raised as to whether this Local Storage or Session Storage data should browse with the user from one computer to another, or whether it should remain on the computer where it was originally run.  Personally, I would think that would be a per computer item, and not go with the user on any computer, and therefore %LocalAppData% or the ability to segment to %LocalAppData% would be appreciated.  However, others may have a different opinion.

Otherwise, if there is some way to limit the amount of data in "Local Storage" and "Session Storage", either via amount of time, or number of sites or size of this, that would also be appreciated.

Thanks!

If we are going to implement this change, I think it would make sense to only move directories where we are sure that the user sees no difference if they suddenly go missing.

What would happen for users who already use the policy to redirect cache directories:
Current Chrome release:
  GPUCache is profile/../GPUCache
  Local Storage is in profile/Local Storage

New Chrome release where we move everything:
  GPUCache might be in <user_configured_dir>/../GPUCache
  Local Storage might be in <user_configured_dir>/Local Storage

Now I assume that we won't implement additional logic to store the old path, notice the change, and actually move the contents of the directories to the new location, so changing the path looks like deleting the contents to the browser.
I assume that deleting contents of GPUCache is not noticeable by the user, because it will be re-created.
Deleting contents of Local Storage would probably affect the function of some websites.

That's why I'd like to limit this to directories which will be re-created transparently on the fly.

+Michael
Please see Comment #9 -- do know if there is a size limit for Local Storage / Session Storage?

Assigning to blumberg@ for triage.

Actually - I don't think we should move blob storage directory. Yes, it's ephemeral, but it's not really a 'cache'. This data can't be removed while a webpage is running and have the webpage continue to function, as some of it's data will be gone.

I guess I want clarification - why do customers want this file changed? Is this so they can do stuff like clear it? What is the functionality here?

I suggested blob_storage because I didn't know if it's cache-like or not.
The problem is that its outdated contents is not automatically cleared when no longer used, which seems a separate bug.

As for the general purpose of %subject%, personally I use a RAM drive for the cache-like stuff as it's MUCH faster even than an SSD I also have.
Many people run Chrome off a networked drive so they want to have the cache-like stuff in a local directory as it makes Chrome much faster.

Ah - blobs are definitely cleaned up as soon as they're no longer used, the only time we leave them around is for shutdown (as the deletion jobs are Skip-on-shutdown). BUT we clean all the old ones up after startup.

To put some enterprise perspective to the question about why would people want to move any kind of transient data from the profile directory is when the prodile is hosted on some form of roamed/synced storage which can be expensive/slow to copy over the network. In such cases having any data that can be rebuilt/redownloaded on local storage or even ram-disks is both a significant performance boost as well as cost reducing factor. This is why we introduced the DiskCacheDir and MediaCacheDir policies back in the day. We might consider offering either a new CacheDir policy that will gather them all or continue doing this on a per cache type base for even more flexibility but either way it is good idea imo.

Related to GPUCache. In Windows GPUCache, as well as ShaderCache/GPUCache and ext/sync-login/def/GPUCache, are in %APPDATA% instead of %LOCALAPPDATA% which means that they get backed up and roam when the user changes computer.

I can imagine this being the same bug but another symptom.

No owner, backlogging