Technology

Or use inotifywait from inotify-tools. It logs acces to specified file/folder.

This is the way.

There's also $HOME/.local/share for 'static data files' as part of XDG.

That doesn't work well for... well, most software I can think of.

Games: I do not want to backup the entire folder to ensure I have my save files. Modern games are huge. I want my saves to be located somewhere easy to get to (for the average user) and be quick to backup, without having to go in and cherry-pick specific files.
There was a good trend of using Documents/My Games, but sadly that seems to have fractured and now there's also Saved Games, savegames, and some software has moved to using %appdata% or just storing saves in the game install location. There's no consistency, it's a real pain in the hole.

DCC software (Blender, Photoshop, whatever): user preferences and config files. Again, I idon't want to backup the entire software, as I'm likely to reinstall it from an official source when migraing/reinstalling to ensure I have the latest updates. However I do want to be able to backup my preferences or plugins easily.

Any software that allows users to customise it: let me backup those preferences without cloning the entire app.

I do wish there was a standardised folder struture for user data, but it's 2023 and the chances of getting Windows/Max/Nix to agree upon and comform to a generic structure as sadly. The only thing I can think of that's the same across platforms is the .ssh folder.

This is the big thing I miss from my “pre-Unix” Mac days. In OS9 and earlier, apps were self contained, and didn’t spread their garbage everywhere. You deleted an app, you deleted all the app. Granted, there was a tradeoff (the parade of conflicting control panels and extensions you had to manually diagnose when your machine went sideways) but I never understood why in the Windows and Linux worlds devs would code so sloppily. Who told that dev my Documents folder is where their nonsense needs to go? That Documents folder is for my use, not theirs.

Still salty after all these years

@TheBaldness
No. Static libraries are a security risk.
@wet_lettuce

For Linux distros everything should use XDG_CONFIG_HOME and distros should start refusing to package anything that doesn't.

And also: where it found the config file it is actually using at the moment. This would cover the 90% of the cases in which you just want to change a single Key to a different value or something or so...

Like $XDG_CONFIG_HOME and $XDG_DATA_HOME?

GoboLinux kind of solved that problem but it hasn't been updated in years.

The XDG Base Directory standard has kinda sorta been doing that; and I like it. Not everything supports it; and it's not perfect, but at least it's better than the wild west that application configs used to be.

The good ol' RTFM

Yeah anything installed via a package manager, like an rpm or deb package, you can query to see what files belong to that package. Problem is they often have default config file locations, like in your home dir, where they will not ship and install files. (Though they might create them as part of a post install process)

~/.config is the non-root version of /etc these days. But you just have to know that, which isn't ideal.

Certainly not. Nothing should write to /usr/bin except for the package manager in FHS distros and some distros binary directories aren't writable at all.

The exceptions should only apply for cases where XDG is not available. In any other case, the appropriate XDG directoy configured by the user should be used first.

Do things stay in that list when they are not used (since they would be opened and closed in far less than a second)? If so that's pretty cool.

If not, you can use Process Monitor to check this. That's what I usually do.

The *nix equivalent is the lsof command. This doesn't help you finding out in which hierarchy config files are parsed when the program accesses multiple ones, which is often the case.

Unless it's using the Registry for some config values.