Just wondering several times about this so I decided to open a thread here. Syncthing uses the XDG_CONFIG_HOME (~/.config) directory for its whole stuff, such as the index files, logs, configs… I think this does not really make sense for all files. There is the XDG_DATA_HOME (~/.local/share/) for this kind of stuff:
$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
As I don’t do MAC or Windows I have found this thread as well. What do you think?
That’s possibly the ugliest path I’ve ever seen suggested… What is local intended to signify here? Local to what? We’re already in my home directory. share? Shared with what or whom? I see the XDG spec alright, but damn… o_O This is one case where the standard existing is not by itself reason for me to think it’s a good idea to follow it… Convince me of the resonableness here please.
On Mac, keeping it all under ~/Library/Application Support is perfectly valid, and I think that’s the case for %LocalAppData% as well on Windows. At least that’s what people said when we made it so.
Well, my first intention for proposing this (without actually questioning the structure itself) is that a lot of programs on linux, especially gnome, use this filesystem structure. As a linux guy I am familiar with it. I had a quick look into that directory on my machine; here is a quick list which programs use it for internal data and logs:
Evolution emails, calendars, contacts
steam
vlc
zeitgeist
virtual box
systemd
geary
local python packages
I guess the intention was that e.g. multiple calender applications should access your calendar database - and assets. There are even libraries which abstract this standard for easier usage.
It is some kind of a “user tree” for /usr/bin, /usr/lib, /var/tmp and, I guess, a combination of /var/lib and /usr/share. So such a ~/.local tree does imo make more sense here than putting data (especially logs) into ~/.config.
~/.local $ la
total 0
drwxr-xr-x 1 stefan users 196 3. Okt 14:28 bin
drwx------ 1 stefan users 18 7. Aug 2014 lib
drwx------ 1 stefan users 1,4K 8. Mär 11:12 share
drwx------ 1 stefan users 68 8. Sep 12:03 tmp
Oh /usr/local/share is fine and has meaning. ~/.local/share I don’t get - why not ~/.data for XDG_DATA_HOME, since XDG_CONFIG_HOME is ~/.config? But this is not the place to debate an existing standard, and if other programs really do use ~/.local/share and users expect that to happen, that’s fine enough. It’s somewhat annoying since it means we get two user specific locations to handle instead of one, but doable. Pull requests accepted.
Local to the user of course. I quite like this folder as I pop an etc, bin and var folder in it and then I know that’s where all my local config is stored and it declutters my home directory.
I do feel that the actual idea of the .local folder is synonymous to the Roaming, Local situation in windows. XDG_CONFIG_HOME is probably for configs that are shared between machines and XDG_DATA_HOME is (I assume) for larger pieces of data meant to remain local to the machine.
I don’t really respect this and decide what I want to sync on a per folder basis under the .local directory. A lot of it is to do with preference.
If the user wants logs in the .local folder so that they don’t sync (in the ideological model of how this foldering works).
Although through the nature of linux, the standard of these XDG folders isn’t so well defined as Windows and Mac OS because not everyone used xdg, etc.
The meaning the pretty much the same as the meaning for share inside /usr: it’s shared across all local applications. Much like /usr/share/themes is read by many, many applications, and ~/.local/share/mail (in my particular case), is read by both apps that synchronize emails, and my mail client, as well as others that need to interact with my mailbox.
Your suggestion that /usr/share is called share because it’s shared across users is plainly wrong, that’s not the origin of the name (and also, keep in mind that all of /usr is shared across all local users).
You yourself stated that on windows this sort of data is stored in /%LocalAppData%, so I don’t see why .local sounds so terribly ugly.
In any case, the spec merely formalized an already widespread standard, and is meant to keep home directories tidy:
Avoid cluttering ~ with dozens of directories.
Keep configuration, user data, and cache separate.
The existence of this thread is a symptom of why GNU/Linux is “not ready for the Desktop” - i.e. not ready for the basic user. It’s stupid and sad there are Ubuntu forum threads asking “What is .local and is it OK that I deleted it?”
You don’t know what combination of kernel and desktop environment your apps will run on… It makes sense to follow the example of other applications and do the following:
Default to ~/.syncthing (or keep the current ~/.config/syncthing) - best on a headless installation to have a single binary and a single application resource folder. Syncthing should not force an arbitrary specification on every user (And XDG is definitely arbitrary)
Allow manual setting of custom config, data and cache locations for advanced users to place resource data where they want it.
Allow automatic setting of custom locations to give more control to 3rd-party developers to store data where it’s best for integration with their wrapper/installer.
I think this fits better with the established Syncthing model of providing an extensible core binary around which we can build our own custom workflows and applications. (also it fits with my view that most users should be using a wrapper/installer and not the bare binary but that’s another discussion )
The mother of my girlfriend keeps asking if she could delete anything on her C:/ directory, because she wants to clean it up. Windows probably let you do that, you just have to click “yes”. So this is not a fair comparison, because windows just cames preinstalled, and every noob buys it by default. A noob does not installs a new operation system. That’s my opinion.
IMO this would be better than putting everything into ~/.config/syncthing. The index database stuff has nothing to do with “config”. So either everything should go into ~/.syncthing or it should be splitted up into the xdg locations.
Sure, some people will always delete random stuff, that’s a given. What I was driving at is that a single folder app-store system is easier to manage, easier to protect, and also easier to educate users about because it makes more sense to them.
For example: You and I can tell people “Yeah, don’t delete App Data, that’s where all your App Data lives… you’ll lose data and your apps will die” You’ll get a response of “Oh sure, that would be bad!”
Try that with “Yeah don’t delete .local, .config, .cache or any of these other random folders because that’s where all your app data lives” The response is “Huh? Why is it called .local? And how am I going to remember all this? Please write it down for me…”
Just the last offtopic post from me. I don’t get your point. These directories are hidden by default (leading dot). Why should a noob even bother with them?
But well, I should shut up now; otherwise I fear to get banned due to silly bikeshedding.
Of course people should not bother with them (BTW, I think the term noob is derogatory here.) But like you said earlier, people sometimes do dumb stuff. So my view is: the greater the number of folders living in home folder, the greater the chances of people screwing stuff up. It’s the responsibility of a developers to minimize those chances however you can.
I know, this is a really old topic. Just want to add that I would also prefer a configurable directory for the index. XDG_CACHE_HOME or ~/.cache/syncthing seems like the natural place for the index on linux to me.
The reason is simply that I see no need to include the index in my backup. I already exclude ~/.cache, but currently I also have to exclude .config/syncthing/index*, since the index can be quite big, changes frequently and the backup would be outdated within minutes.
Yeah, noticed that. Turned out the overwriting issue was due to how brew services copies the master file from /usr/local/opt/syncthing/homebrew.mxcl.syncthing.plist so I had to edit that copy.
I quite like this folder as I pop an etc, bin and var folder in it and then I know that’s where all my local config is stored and it declutters my home directory.
)
I don’t get your point. These directories are hidden by default (leading dot). Why should a noob even bother with them?
