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

wrong cache path #718

Open
532910 opened this issue Oct 6, 2019 · 21 comments
Open

wrong cache path #718

532910 opened this issue Oct 6, 2019 · 21 comments
Labels

Comments

@532910
Copy link

532910 commented Oct 6, 2019

Cache must not be stored in ~/.config/Riot/Cache. There is ~/.cache or $XDG_CACHE_HOME for cache.
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

@532910 532910 added the T-Defect label Oct 6, 2019
@532910 532910 changed the title cache path wrong cache path Oct 6, 2019
@t3chguy
Copy link
Member

t3chguy commented Oct 6, 2019

This is the default location for all electron apps: https://github.com/electron/electron/blob/master/docs/api/app.md#appsetpathname-path

@532910
Copy link
Author

532910 commented Oct 6, 2019

@532910
Copy link
Author

532910 commented Oct 6, 2019

Look like riot should workaround this with app.setPath("cache", "~/.cache")

@foresto
Copy link

foresto commented Jan 26, 2020

Indeed, on linux, Riot creates at least three cache directories under ~/.config/Riot: Cache, Code Cache, and GPUCache. These should be under ~/.cache/Riot instead. They're wasting space in my backup archives, and circumventing the tmpfs I use for cache filesystems.

@532910
Copy link
Author

532910 commented Jan 26, 2020

what is the problem to workaround the path with app.setPath("cache", "~/.cache") ?

@532910
Copy link
Author

532910 commented Jun 12, 2020

Is there any update?

@t3chguy
Copy link
Member

t3chguy commented Jun 12, 2020

No, otherwise you would have seen it here.

@532910
Copy link
Author

532910 commented Jun 12, 2020

what's wrong to workaround with app.setPath?

@t3chguy
Copy link
Member

t3chguy commented Jun 12, 2020

Best off asking the Electron team that, they must have a reason for not using it.
I'd imagine ~/.cache isn't available on absolutely every single supported Linux environment.

@532910
Copy link
Author

532910 commented Jun 12, 2020

.cache and .config are both from the same specification:
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
https://wiki.archlinux.org/index.php/XDG_Base_Directory

@t3chguy
Copy link
Member

t3chguy commented Jun 12, 2020

Doesn't mean that .config isn't also specified by some other standard.
As I already said, this would be best done upstream.

@t3chguy
Copy link
Member

t3chguy commented Jun 12, 2020

According to electron/electron#8124 setting cache dir won't fix it anyway:

Cache data is written to userData dir instead of cache dir

@DC7IA
Copy link

DC7IA commented Oct 12, 2021

Cache must be in ~/.cache not in ~/.config/Riot/Cache

Please read the XDG Base Dir Specification. If the variables are set the path must be derived from them. Not always is it ~/.cache.

https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

@DC7IA
Copy link

DC7IA commented Oct 12, 2021

This is the default location for all electron apps: https://github.com/electron/electron/blob/master/docs/api/app.md#appsetpathname-path

It doesn't make it alright.

@DC7IA
Copy link

DC7IA commented Oct 12, 2021

Look like riot should workaround this with app.setPath("cache", "~/.cache")

Yeah, but instead read the variable and only fallback if it isn't set:

$XDG_CACHE_HOME defines the base directory relative to which user-specific non-essential data files should be stored. If $XDG_CACHE_HOME is either not set or empty, a default equal to $HOME/.cache should be used.

(From the specification)

@DC7IA
Copy link

DC7IA commented Oct 12, 2021

they must have a reason for not using it.

They probably did not read the specification or don't care about standards.

@532910
Copy link
Author

532910 commented Oct 12, 2021

Please read the XDG Base Dir Specification. If the variables are set the path must be derived from them. Not always is it ~/.cache.

Comment updated, is it better now? It doesn't change anything anyway, since the main message was that it shouldn't be in ~/.config.

@DC7IA
Copy link

DC7IA commented Oct 30, 2021

This is the default location for all electron apps

Just because they don't read standards does not mean it has to be reproduced.

$XDG_CONFIG_HOME is supposed to be a folder you can simply copy to new machines or sync to other machines.

This likely breaks badly if I try to sync with other machines.

@DC7IA
Copy link

DC7IA commented May 9, 2022

Seems to have been solved in upstream, electron/electron#33554 has been merged and closed.

@rugk
Copy link

rugk commented May 9, 2022

Great! Though the PR says it "allow[s] customizing browser data location" and goes on to explain how one (i.e. electron dev) can actually use that. As such, I guess as for Element there is still something to do, i.e. actually configure it to use the "correct" locations… (still wonder why they don't use/include the proper defaults then in Electron upstream?)

@t3chguy t3chguy transferred this issue from element-hq/element-web Apr 18, 2023
@Zocker1999NET
Copy link

Zocker1999NET commented Apr 29, 2023

(still wonder why they don't use/include the proper defaults then in Electron upstream?)

The problem seems to be that Chromium doesn't seem to want to adhere to XDGBDS and just packs everything into this single directory (1 2). So the Electron devs were only able to separate Session & User data from one and another. So Electron cannot just move these directories to $XDG_CACHE_HOME as then also Cookies & Web Storage would be stored there as well and some Electron apps store valuable data there.

As an example, Trilium Notes uses its own data directory, so doesn't depend on Cookies/Web Storage, which should enable it to just treat the Electron directories as cache.

Sadly for this, Element seems to use the Cookies & Web Storage and so cannot just easily separate them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants