Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not use ~/.config on Linux to store cache and local information #137

Open
ghost opened this issue Jul 8, 2017 · 6 comments
Open

Do not use ~/.config on Linux to store cache and local information #137

ghost opened this issue Jul 8, 2017 · 6 comments
Assignees
Projects
Milestone

Comments

@ghost
Copy link

ghost commented Jul 8, 2017

The ~/.config directory (or whatever $XDG_CONFIG_HOMEis set to) on Linux is designed to be a place where configuration files are stored; this makes it easy to back up the configuration of many installed programs at once.

At the moment, Sciencefair seems to store a large amount of cache and user data in this directory. This might be experienced as a nuisance by users who rely on the relevant conventions, because it contaminates their backups with non-config data. It might be better to store cache and user data in directories which are intended for that purpose ($XDG_DATA_HOME / ~/.local/shareand $XDG_CACHE_HOME / ~/.cache, respectively).

More information about these directories can be found here: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

@blahah blahah self-assigned this Jul 8, 2017
@blahah
Copy link
Member

blahah commented Jul 8, 2017

@mrbiber can you please paste an ls -alh of what's in the sciencefair dir in ~/.config (after redacting anything sensitive)? AFAIK we shouldn't be storing things there, so this seems like a bug.

@blahah blahah added this to the v1.1 milestone Jul 8, 2017
@ghost
Copy link
Author

ghost commented Jul 8, 2017

$> find .config/sciencefair -printf '%s %p\n' 
4096 .config/sciencefair
4096 .config/sciencefair/Cache
8192 .config/sciencefair/Cache/data_2
524656 .config/sciencefair/Cache/index
270336 .config/sciencefair/Cache/data_1
8192 .config/sciencefair/Cache/data_0
8192 .config/sciencefair/Cache/data_3
7168 .config/sciencefair/Cookies
69 .config/sciencefair/Preferences
0 .config/sciencefair/Cookies-journal
4096 .config/sciencefair/Local Storage
3072 .config/sciencefair/Local Storage/file__0.localstorage
0 .config/sciencefair/Local Storage/file__0.localstorage-journal
4096 .config/sciencefair/GPUCache
8192 .config/sciencefair/GPUCache/data_2
262512 .config/sciencefair/GPUCache/index
270336 .config/sciencefair/GPUCache/data_1
8192 .config/sciencefair/GPUCache/data_0
8192 .config/sciencefair/GPUCache/data_3

@blahah
Copy link
Member

blahah commented Jul 8, 2017

thanks @mrbiber - it looks like this is where Electron stores its chromium config and cache, and it's a known (and widely discussed) issue: atom/atom#8281

@blahah
Copy link
Member

blahah commented Jul 8, 2017

@mrbiber I'm going to fix this with a module that sets sane paths for electron's cache, config etc., as suggested here.

@blahah
Copy link
Member

blahah commented Jul 8, 2017

Actually, it seems this might currently not be possible. Chromium is setting those caches: https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md#User-Cache-Directory. It ignores Electron's cache path config for the browser cache.

Electron issue here: electron/electron#8124

@blahah blahah added this to diagnosed in v1.0 bugs Jul 10, 2017
@step21
Copy link

step21 commented Aug 18, 2017

Additionally, apart from the issues with electron/chromium itself - most electron apps have the same issues and many/some other apps also do not stick to this convention. F.e. Virtualbox keeps its logs there and the Guest Additions iso (plus some other stuff) - which you might want to back up, but they are not configuration. So I maybe wouldn't make this a high priority...

@blahah blahah added the blocked label Oct 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
v1.0 bugs
diagnosed
Development

No branches or pull requests

2 participants