Cache location of Linux client does not comply with XDG Base Directory Specification

[E1k3]

• I have searched open and closed issues for duplicates

Bug Description

The Signal desktop client on Linux stores its cache and runtime files in ~/.config/Signal/. This is not what the .config directory is for.

According to the freedesktop.org XDG Base Directory Specification , these files should be stored in $XDG_RUNTIME_DIR/Signal/, $XDG_CACHE_HOME/Signal/ or $XDG_DATA_HOME/Signal/ depending on their lifetime and redundancy.

Steps to Reproduce

1. Install Signal
2. Start Signal
3. Watch Signal flood your .config directory.

Actual Result:
Signal creates a .config/Signal directory and stores all configuration (that one's ok), history, cache and runtime data (those are not ok) in this directory.

Expected Result:
Signal creates the correct directories in $XDG_CONFIG_HOME, $XDG_RUNTIME_DIR, $XDG_CACHE_HOME and $XDG_DATA_HOME and uses them as expected.
If for example SingletonCookie, SingletonLock and SS are only required during Signal's runtime, they should be created in $XDG_RUNTIME_DIR/Signal/, if Cache only contains cached data, it should be stored in $XDG_CACHE_HOME/Signal, and so on.

Platform Info

Signal Version: v1.39.6

Operating System:
ArchLinux 5.10.9-arch1-1

Linked Device Version:
Not relevant.

Link to Debug Log

Not relevant.

[Exploder98]

This might be something caused by Electron, as other Electron applications I use (Discord, Slack, Teams etc.) seem to behave similarly, flooding the ~/.config directory.

[E1k3]

This behaviour is wide spread in electron apps, because ~/.config/app_name is the default user data directory in chromium, but that does not force any specific electron app to use the wrong directory.

See electron/electron#8124

Why reproduce a bug just because the chromium devs decided to ignore a widely accepted specification for some reason?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Exploder98]

I think this is still a thing.

[indutny-signal]

Sorry about this. It is on our radar now.

[DC7IA]

Same applies to lock files.

$XDG_CONFIG_HOME is for configs, nothing else.

It's so annoying when you synchronise your config folder between devices and then software breaks because multiple running instances put their stupid lock files in the config directory.

A lock file is just not config.

[DC7IA]

In a perfect world people could just sync their config dir and when they install the same software on another device things just magically work.

[hiqua]

Note that you're still going to have problems if you run Signal-Desktop on several devices using the same config folder at the same time, so it makes sense to have a lock file there to try and prevent this.

You can link the other device separately if you want to use Signal-Desktop there as well.

[DC7IA]

Note that you're still going to have problems if you run Signal-Desktop on several devices using the same config folder

The config folder should only contain settings like the theme and notifications.

State information and cache and keys and message db and so on are not config and must not be saved in that folder.

[E1k3]

@hiqua That is exactly what this issue is about. If the config directory only contained configuration and no message store, lock files or other non-config data, users would be able to sync that directory between clients without problems to keep their config consistent between devices.

Linking two devices separately does not even work for this, because the client configuration (appearance, spell check, notifications, etc.) is not synced by linking.

[EvanHahn-Signal]

This is a bug in Electron. Let's move discussion there: electron/electron#8124

[E1k3]

When I opened this issue, there was no real interest in fixing this in electron. Reasons were the transition from the old system might be hard and that further upstream, chromium was and is not interested in fixing things.

Since there is a now a PR (electron/electron#30665) close to being merged, I agree that an upstream fix would be the better option.

[baj0k]

The PR mentioned by the @E1k3 was closed, however the work was continued in other PR (link).

Just wanted to mention that the PR was recently merged.

[E1k3]

electron/electron#33554 is really not a solution to this problem and it is not intended to be one (neither was electron/electron#30665 as it turns out). The user data is still not separate from config, behaviour is still wrong by default and as the name browserData suggests, the change only affects the chromium browser cache and not the remaining application cache.
That said, it would be a good first step to set browserDatato $XDG_CACHE_HOME (falling back to ~/.cache/Signal).

Since the main problem will not be solved by electron in the foreseeable future, I would suggest storing signal cache manually in $XDG_CACHE_HOME (falling back to ~/.cache/Signal), user data in $XDG_DATA_HOME (falling back to ~/.local/share/Signal), which leaves the config in $XDG_CONFIG_HOME (falling back to ~/.config/Signal.

[pm4rcin]

I'll leave a link to PR to track the progress electron/electron#34337