Do not save apps/cache/downloads etc in ~/.config

[shunsei]

On linux ~/.config/itch/ contains all kinds of stuff that is not configuration files.

Please follow proper conventions and save cache files in ~/.cache/ and data files in ~/.local/share.

[fasterthanlime]

Electron apps treat ~/.config/[appname] as if they were C:/Users/[user]/AppData/Roaming/[appname] or ~/Library/Application Support/[appname], making Linux a special case would add a lot of complexity (and probably bugs), I'm not entirely convinced it's worth it.

Is the problem for you that you're backing up ~/.config, @shunsei ?

[shunsei]

Yes, there are multiple use cases this is interfering with.

1. It should be possible to keep ~/.config/ under version control or back it up without backing up data files.
2. It should be possible to free up disk space by cleaning up ~/.cache.
3. It should be possible to use another partition for data files (eg. ~/.local/share).

And so on.

I don't know anything about Electron, but sounds like it should not be using ~/.config. If it's going to be a large dump of mixed-purpose files anyway, better move the directory elsewhere altogether (eg.~/.itch), although that would be just a workaround.

[fasterthanlime]

@shunsei just to clarify (my initial response had a rather bland tone): I completely sympathize with your request.

let's look at practical fixes:

• electron upstream is not going to change default locations anytime soon, as far as I can tell. This would break old applications.

However, there is an app.setPath method that can be called before the app is ready, that can adjust some paths. See this list.

So, it would be possible for the itch app to set different directories - but I'm not sure how to proceed in a backwards-compatible manner. It has been using ~/.config/itch (or $XDG_CONFIG_HOME/itch) for a while, and I can't implement a "migration assistant" within the app, since setPath needs to be called before the app is ready (so, before I can show any UI, for example), and doing it while the app is running isn't possible either (Chrome locks some files, so they can't be deleted/moved).

---

One possible way to do it would be:

• On startup, the itch app synchronously checks for the existence of ~/.config/itch/Preferences - that's a file Chrome (and thus electron) creates on a startup.
• If it exists, it operates from ~/.config/itch
• If it doesn't, it operates from ~/.itch

Then, users could manually mv ~/.config/itch ~/.itch while the app isn't running. It might also be possible for the app to do itself on startup, synchronously (before the app has time to get ready), although if ~/.config and ~/.itch are on different partitions, it might fail (because then a rename operation won't work, only copying then deleting the original files would). That's a lot of things to do synchronously :/

---

Quick note on synchronicity

V8/Electron are basically big event machines. When starting up, it requires everything - when it does, each module owns the CPU - no other javascript code is executing at this time. Any synchronous operation (fs.writeFileSync for example) will retain control of the CPU. Asynchronous operations (fs.writeFile(function () { /* done! */ })) however, will relinquish control of the CPU, letting it execute something else.

It's going to be tricky to write the entire ~/.config/itch => ~/.itch migration routine entirely synchronously to make sure we own the CPU the whole time and the app doesn't have a change to get ready (which it does, once all required modules have given up controle of the CPU).

(It will also look like the app is taking forever to start, which is bad)

I hope this makes sense.

Another option would be to ship a native executable (I'd go with golang) which role would be to:

• kill the itch app
• migrate from ~/.config/itch to ~/.itch
• launch the itch app again (detached)
• exit

---

Lastly, ~/.itch was actually where I was thinking of having itchSetup install the itch app, so the final path may end up being ~/.itch/data instead.

I hope you understand why it's not done yet :)

---

Edit: a last solution comes to mind. If only tech-savvy users care about migrating ~/.config/itch to ~/.itch, the app could accept a --migrate-config argument, and behave as a CLI tool. If it doesn't open any windows, Chrome shouldn't get a chance to lock files and it wouldn't fail.

[shunsei]

Sounds pretty involved. From reading the Electron docs, appData really should not be pointing to $XDG_CONFIG_HOME, if it's touted as a generic "application data directory" (although userData does mention it's only for configuration).

I personally wouldn't mind having to move the directory manually, it's a one-time migration after all.

Would this new ~/.itch directory still contain all different kinds of files though?

[fasterthanlime]

Would this new ~/.itch directory still contain all different kinds of files though?

Yep, except if we go even more involved and start splitting folders even more.

My original design intention was that: chrome cache files should be small enough that it shouldn't matter where they're stored (I know it's not true for everyone 😞) - games/installed items are the main consumer of disk space, so you should get to pick where they're installed. Downloads also go wherever your main "install location" is.

[fasterthanlime]

itch v25 is out, and:

• it ships with a new installer system
• which installs itch binaries to ~/.itch
• and config/cookies/etc. to ~/.config/itch
• and you can add other install locations if you don't want to use the default location that's ~/.config/itch/apps.

[sparr]

I am depressed to see that the decision was made to migrate from ~/.config/foo to ~/.foo instead of the appropriate ~/.local/share/foo and ~/.cache as suggested in the original issue report here.

[fasterthanlime]

I am depressed to see that the decision was made to migrate from ~/.config/foo to ~/.foo instead of the appropriate ~/.local/share/foo and ~/.cache as suggested in the original issue report here.

So, let's fix that.

What changed (between .deb/.rpm packages and itch-setup) was: the app's binaries moved from /usr/lib/itch to ~/.itch. Stuff that was in ~/.config/itch stayed where it was.

Now that itch-setup is a thing, and it works well, there is a path for me to migrate the ~/.itch stuff to ~/.local/share/itch and the ~/.config/itch to.. somewhere else, but probably not ~/.cache ? I don't know what a good default install location would be.

Anyway, please don't get depressed over that. I didn't just ignore all the feedback, there were a lot of tricky things to get right, and now that v25's been out for a while and is stable, we can:

• Switch to different paths for clean installs
• Eventually provide a reseat command for itch-setup (so it can move stuff around to the new locations).

I've just opened #2252 to track that.

[fasterthanlime]

Thinking about this some more, /cc @shunsei @sparr

Currently, itch v25 uses two directories:

• ~/.itch (where itch-setup installs binaries), which contains:
  • The itch binary itself (modified electron binary)
  • A bundle of javascript code (compiled from TypeScript, ie. the code in this repository)
  • Native dependencies like node, ffmpeg, ICU data, locales (part of a standard electron distribution)
  • A copy of itch-setup, for launch purposes (that's what shortcuts point to)
  • A state.json file that describes which version of itch is installed, if any other version is ready to be deployed, etc. (that's what itch-setup uses to decide what's installed, if it needs to be updated, what version to relaunch, etc.)
• ~/.config/itch (Electron's default userData), which contains:
  • Config stuff:
    • A config.json file with window positions/sizes (historical, not that important)
    • A preferences.json file with your itch app preferences. Those are mostly cosmetic. The important stuff is in db/, see below
  • Components/binary stuff:
    • broth/, contains butler (for everything from API requests to installing/updating/configuring/launching/sandboxing/uninstalling games - it effectively is itch v25 except for the UI which is in electron), and itch-setup (for self-update). Removing that will just re-install them on next app start. Removing it while the app is running is, uh, going to leave it in a bad state.
  • Data stuff:
    • apps/, the default install location for games. You don't need to use that install location.
  • Temporary stuff:
    • logs/, containing JSON logs for the app
    • GPUCache/: pure cache, can be removed without losing anything
    • locales/: contains as more up-to-date version of translation strings. This one is going to disappear anyway. The app can function with only the bundled locales, which are in ~/.itch
  • Mixed stuff:
    • db/, containing the SQLite database for the app, which has both credentials (for logged in acounts), and a cached copy of some games, collections, users, download keys records, and info on installed games, also your set of opened tabs/history.
    • Partitions/: contains cookies, localStorage etc. for all sessions - including the app itself (game covers for example, available offline because they're in that cache), webpages inside the app (making visiting websites faster), but also HTML5 games (so, effectively, your save files). Removing that would free disk space (it's at 91MB for me right now), but you'd lose your game saves.

So, with all that in mind, I'm not sure that I can map this cleanly to ~/.local/share/itch and ~/.cache

The only good candidate for ~/.cache (since that's supposed to be a directory) is.. GPUCache/. That's it. Everything else is not a pure cache (Partitions has game saves, db has installed game info, your login credentials, etc. - removing it would force you to re-log-in, re-scan for games, etc.)

As for ~/.local/share/itch, I've been going through mine to see what apps put in there, and.. I'm still not sure what it's for. I guess it's a better destination for "a mixed bunch of things" than ~/.config/itch.

Splitting up what currently goes in ~/.config/itch would be a headache - and by that I also mean "it could potentially blow up linux folks' install and take a while to resolve", which I really don't want. So, keeping all that in mind, how about:

• Changing ~/.config/itch to ~/.local/share/itch
• Changing ~/.itch to ~/.local/lib/itch

Which leaves us with the following problems:

• Actual config files are not in ~/.config - but config.json and preferences.json don't matter much, and db/ (which has some preferences that matter a lot) contains as lot of other things you probably don't want to back up with your config
• Actual cache files are still in ~/.local/share/itch (like GPUCache/ and Partitions/), instead of ~/.cache, so you can't clear them by doing rm -rf ~/.cache. The thing is, I don't think it's possible to specify explicit paths for electron partitions (think of them as web sessions - the itch app UI has its own, itch app webviews have another, each HTML5 game has one).

Would that be a step in the right direction or? I'm sort of debating what the advantages here would be compared to the amount of work it is.

[eevee]

Yeah, given that ~/.local/share is basically a junk drawer, I think the only Not Wrong option is to cram everything in there. If you can't break out config/cache, it's better to put config/cache in a more general place than to also put unrelated stuff in a more specific place.

[paulloz]

My two cents on the matter. I second the comment above.

Currently most of what's under ~/.config/itch/ would be better off in ~/.local/share/itch/. Keeping the actual configuration files under ~/.config/itch/ would be nice but if splitting up the folders are error prone for now, I'd rather see everything move out.
I personally don't like the idea of moving the content of ~/.itch/ to ~/.local/lib/itch/: itch and itch-setup doesn't belong there (at least). In addition I'm pretty sure this is not an XDG folder.
As for ~/.cache/, how disk consuming is the GPUCache/ folder anyway? I'm not sure this is a huge issue at the moment.

[fasterthanlime]

GPUCache is less than one megabyte for me atm (but the app is not running). The larger caches are in Partitions, they're mostly images but mixed in with HTML5 save data / cookies

…

On Sat, Feb 23, 2019, 17:28 Paul Joannon ***@***.***> wrote: My two cents on the matter. I second the comment above. Currently most of what's under ~/.config/itch/ would be better off in ~/.local/share/itch/. Keeping the actual configuration files under ~/.config/itch/ would be nice but if splitting up the folders are error prone for now, I'd rather see everything move out. I personally don't like the idea of moving the content of ~/.itch/ to ~/.local/lib/itch/: itch and itch-setup doesn't belong there. In addition I'm pretty sure this is not an XDG folder. As for ~/.cache/, how disk consuming is the GPUCache/ folder anyway? I'm not sure this is a huge issue at the moment. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHoLZkb1px0IogWcV0nI2fg1FGOxqSgDks5vQWwegaJpZM4M3xRw> .

[fasterthanlime]

So, moving ~/.config/itch to ~/.local/share/itch seems like a good (achievable) first step?

It would:

• Leave ~/.config alone
• Not use any of the non-XDG dirs like ~/.local/lib, ~/.local/bin
• Not solve ~/.itch, but, shrug

The process would be:

• Existing installs are left alone
• itch v25.5.0 would check for, mhh ~/.config/itch/db/butler.db - if it can find it, it'll use ~/.config (legacy paths), if not, it'll use ~/.local/share/itch (modern paths)
• Users who want to reseat can just completely quit itch (Ctrl+Q), mv ~/.config/itch ~/.local/share/itch, start it up again, and voilà!

The only remaining file any of the tools would write to itch would be... ~/.config/itch/butler_creds, which is, well, actually used by butler to store your credentials. That doesn't really belong in config either, maybe it could move to ~/.local/share/butler/credentials ?

(Please vote 👍 or 👎 using comment reactions - if you vote against, please explain)

[fasterthanlime]

(note that, anywhere I say ~/.config, I mean $XDG_CONFIG_HOME falling back to $HOME/.config, and the same is true for ~/.local/share, ~/.cache etc.)

[dos1]

butler_creds feels like could (or even should) stay in .config actually. Other than that, it's pretty much what I'd do myself ;)

[tpruzina]

What I expect to be in user directories (~user/<dir>/<appname>) goes along those lines:
.config - user editable configuration (no database files, serialized crap or anything like that)
.cache - cache files, user deletable in between sessions (e.g. your stuff needs to work whether or not this exists, is read writable, ...)
.local/{share,lib,...}/ - random cruft, can be icons, database files, libraries or serialized data

Alternatively, start saving everything into ~user/.<appname>, and do whatever you want in there.

[kuon]

Just don't use ~/.itch (https://0x46.net/thoughts/2019/02/01/dotfile-madness/)

I'd put everything in $XDG_DATA_HOME. $XDG_CONFIG_HOME should only contain configuration that is intended to be edited "by hand". But if your config file is human readable and lives in the data folder, I don't case as long as I don't have to edit it.

For the cache dir, be sure to support its deletion, I delete mine regularly.

[fasterthanlime]

Just don't use ~/.itch (https://0x46.net/thoughts/2019/02/01/dotfile-madness/)

So, here's the thing that bothers me about this article: it says "just read the standard and follow it, duh!" - well, I've read the standard, a dozen times, and it doesn't say where to put applications that don't need root to be installed

I'm familiar with package manager guidelines that have strong opinions on where to put everything (and it differs by distro! Even after FHS!), and I'm still not convinced it's not a big ol' waste of time.

No, you don't need to edit any of the files itch drops on disk by hand, ever. You might want to force a clean install of the binaries, in which case you can just rm -rf ~/.itch - and your data is all still there. (The desktop shortcut that's install points to itch-setup --prefer-launch, which will repair your itch binaries if they're missing).

Again, ~/.local/lib and ~/.local/bin are not XDG standard directories. In fact, the whole ~/.local directory is a junk drawer. There's caches in there, you don't get rid of them by periodically running ~/.cache. Also, modern apps have cached data interleaved with other stuff for efficiency (you might want to use it in queries, it's less I/O operations, etc.)

How often do you actually ls -lhA ~ and what do you do it for? I'm still not convinced the entire reason behind these complaints is anything but ideological purity, which, uh, I don't have enough time for :(

[kuon]

I agree, the standard is not clear. Personally, I use arch and just create an AUR for all apps, except like 2 or three app images I use, I put those in ~/Apps/ but I didn't think about it, so I don't really know the best practice to install binaries in your home.

I'm against filling the home dir with folders because many file pickers display them, and it drives me crazy.

It's not your fault of course. But here is a save panel from firefox.

[MestreLion]

+1 for using ~/.local/share/itch for everything (since splitting is not easy/feasible)! It's a much much better "general purpose" area than ~/.config, and please never ever use ~/.itch!

Is this the current behavior? If so, please update https://itch.io/docs/itch/installing/linux/

By the way... there's absolutely nothing wrong using ~/.local/share/itch/bin to save executables. Sure, ~/.local/bin would be slightly better, (Python's pip already uses it), as it has the bonus of being added to $PATH if it exists in the default ~/.bashrc of many distros (including Debian/Ubuntu) since... 2016? But ok, it's merely a convention, not an official part of XDG spec.

XDG is not that complicated, if you think of its counterparts:

• XDG_DATA_HOME (~/.local/share) would be the equivalent of /usr/share: Big data, mostly binary, mostly read-only except when installing and removing stuff (like games)
• XDG_CONFIG_HOME (~/.config) would be a mix of /etc and /var: writable, persistent area, mostly for config files that user can edit. The debate is whether binary files (like saved games or config sqlite dbs) are welcome here. I personally think they are. If it's my stuff (not game data), and it gets changed regularly, I don't mind if it's not an INI/JSON.
• XDG_CACHE_DIR (~/.cache) would be the equivalent of /tmp: writable, non-persistent area. Unless you want to cache thumbnails or keep downloaded files (not their extracted installs), don't bother.

TL/DR: When in doubt, keep everything in XDG_DATA_HOME. It's a great compromise. It's far better than any other single-dir solution. And avoid using ~/.itchio at all costs, please!

[ParaplegicRacehorse]

+1 for use of XDG_DATA_HOME instead of XDG_CONFIG_HOME

Do not, under any circumstances, pollute my $HOME with a dot-directory which belongs in one of the XDG dirs.

[MestreLion]

@fasterthanlime

I'm still not convinced it's not a big ol' waste of time.

XDG is an attempt to create standards and guidelines on user's home, much like FHS does for the system. Splitting applications' data in several locations (/usr/share, /etc, /var) is common practice in any POSIX/Unix-like system, long before FHS, from Linux to BSD to MacOS. XDG did not invent this.

Again, ~/.local/lib and ~/.local/bin are not XDG standard directories.

They are not, but they're quite established conventions used by many software. And itch does not even need it: being a desktop application, you can set its .desktop launcher to point directly to its executable. It doesn't need to be in $PATH.

In fact, the whole ~/.local directory is a junk drawer.

No, it is not. Mine has only bin, lib and share subdirs. Most users have only share. And ~/.local/share has basically a subdir for each application, along with a few special subdirs: applications, icons, etc. That's much less junk than /usr/share.

There's caches in there

No there is not, unless inside a given application's ~/.local/share/myapp. And in that case I don't care if it makes its own subdir a junk drawer. Whatever goes inside ~/.local/share/myapp is considered implementation detail I don't need/have (or should) mess with.

How often do you actually ls -lhA ~ and what do you do it for? I'm still not convinced the entire reason behind these complaints is anything but ideological purity, which, uh, I don't have enough time for :(

It does make backups and system migrations a whole lot easier. Instead of special case every dotfile/dotdir of every app in my $HOME's root, I can simply backup/migrate ~/.config and all my settings are saved. I can choose to either save ~/.local or just let it re-create itself by re-installing stuff. And finally I can also delete ~/.cache anytime with no functionality loss.

[MestreLion]

Yes, software that existed long before XDG (or even FHS) still require special-casing, such as ~/.ssh or ~/.bashrc. That's not the case of itch, so we would really appreciate we didn't have to add yet-one-more-manually-included-exception to our already long backup scripts.

[ChristianSilvermoon]

I'm also bothered by this.

My current work around is to always execute Itch like so

HOME="$HOME/.local/opt/itch" ./itch

I currently use a wrapper script to do this for me and have my .desktop entry pointed at the wrapper script

Worth noting ~/.local/opt is also non-standard, but it makes sense to me as a user-level mimicry of the Hierarchy Standard, which is also kind of done with things like ~/.local/lib that a lot of other things do.

[jrom99]

Is there any way to force itch to look for files inside .local/share insted of .config? Would it respect a symlink? Also, considering this is all done at setup, wouldn't it be better to move this issue to https://github.com/itchio/itch-setup/issues?

[ChristianSilvermoon]

Is there any way to force itch to look for files inside .local/share insted of .config? Would it respect a symlink? Also, considering this is all done at setup, wouldn't it be better to move this issue to https://github.com/itchio/itch-setup/issues?

You could consider copying my method and doing

HOME="$HOME/.local/share/itch" ./itch

To force Itch to use that directory. It is worth noting that my solution comes with numerous (mostly benign) caveats that require creating Symbolic Links to your proper home directory to correct since this makes Itch treat the folder in question as your home directory.

At the very least I needed to symlink the following into the False Home Directory:

Directory	Reason
~/.themes	User-side themes
~/.icons	User-side icon/cursors
~/.local/share/icons	User-side Icons/Cursors
~/.local/share/fonts	User-side Fonts
~/.var	Flatpak Support
~/.local/share/flatpak	Flatpak Support

Most of these are optional, but I needed flatpak support for at least one title.

Use relative symlinks (AKA ../../../.themes and NOT ~/.themes) where possible, as migrating this setup to a different username will otherwise break your symlinks.

This is not ideal, but it's the best solution I know of.

[jrom99]

This still doesn't solve the ~/.config/ situation, does it? I don't mind dotfiles on my $HOME, but a huge .config/ dir is another matter altogether.

[ChristianSilvermoon]

This still doesn't solve the ~/.config/ situation, does it? I don't mind dotfiles on my $HOME, but a huge .config/ dir is another matter altogether.

This workaround causes Itch to instead use ~/.local/share/itch/.config/itch rather than ~/.config/itch :P

It's not perfect, but it does prevent home directory clutter and keeps your Itch data out of your usual ~/.config and instead under ~/.local/share/itch

[sparr]

You could use unionfs to union mount your fake home on top of your real home and avoid needing the symlinks.