291–300 of 534 posts
Earlier quoted context omitted.
Respectful Windows apps should drop their leftovers under %UserProfile%\Application Data or %UserProfile%\Local Settings\Application Data .
This x1000 but even Microsoft products are creating dotfiles in the users profile directory now and not in AppData where they should be.
Madness.
Earlier quoted context omitted.
The way most editors save a file is like this: f = open("the_file.new") write(f, new_contents); close(f); rename("the_file", "the_file~"); rename("the_file.new", "the_file"); So the old file is never modified, it's renamed to the backup copy, and an entirely new file is created to take its place. This has a number of advantages, but does not play well with any extended info the old file used to have, unless they are…
If you do not rename files while holding their open file descriptors there's no guarantee that you are renaming the file you just wrote to.
To name and shame some culprits (the one's who have shame, I won't name java because I won't expect them to care) 1) Mozilla 2) Gnome 3) Gimp 4) GPG 5) Thunderbird (Why is there a sep directory and not under .mozilla) 6) mplayer I guess one reason why this occurs is that it's easier for to be carelessly cross-platform this way. Except you'd expect better from mozilla, specially because they store Windows stuff very w…
Speaking of Windows, their situation is worse. I remember installing a couple of games and suddenly my "My Documents" folder had "EA", "EA Games", "Electronic arts", "Rockstar games" folders.
I have been fighting this but I gave up: people just don't care or are somewhat opposed, even when presented with a backword compatible patch. Now I just mount the home directory with rewritefs and try make the mess more or less compliant to the spec. It's not ideal: it's a hack and it causes a performance hit but I can be at peace in my ~.
What were some of the reasons people opposed it?
To me, the real problem is not the dotfiles, but the regular (i.e. non-hidden) files that applications surreptitiously create in my home folder. (Which the author does mention as being particularly bad.) dotfiles in the home folder are not a new thing on Linux (e.g. .bashrc, .profile, .emacs, etc.), even if it would be better if more applications used the XDG folders. And if I don't see them when I "ls", they don't b…
From my impression the answer was more "we set up things in a hurry because of deadlines and now we are stuck with this until we implement the epoch system"
Earlier quoted context omitted.
Why wouldn't it to be easy to implement? You could probably make a global LD_PRELOAD library that hooks into all open() CREAT calls and tags the inode's xattr with the program that created the file. You could use an attribute like, user.created_by.
Programs can use programs like 'touch' to create the files so you'd have to get meta into a chain of process ownership or something while exempting the user's shell.
Earlier quoted context omitted.
This is particularly weird, since click (snap's "predecessor" at Canonical/Ubuntu) was fully XDG compliant, even encouraging developers to separate data from cache etc. (unlike flatpak which just dumps everything in ~/.local/share/[...], though that is still infinitely better than using ~/snap).
I personally don't like xdg. I have bin files from pip and other stuff in ~/.local/bin. I have huge amounts of cache files in both .cache and .config. It's supposed to make my life easier by being able to backup .config and dump everything. but in reality this doesnt happen. Backing up .config for just the user defined configs is a massive PITA. you have to put so many gitignore exceptions and I'm not even talking ab…
Earlier quoted context omitted.
It's senseless to store files that don't have user-facing meaning in My Documents. I know games that use it varyingly for web caches, shader caches, binary config files, debug logs, Lua scripts, downloaded mods, and even executables . And while arguably most gamers understand what save files are , they can't be double-clicked to open them, so I don't consider them documents (Maybe this is pedantic). All this kind of…
Save games is a poor example. Users often need to back them up. Backup systems often include Documents by default but not AppData. Files in AppData are hidden, and you would not expect users to find them. Further, many save games can be opened with a text editor just fine :)
One thing I’ve been thinking about is that it would be nice to tag files with the program that created them. Aside from the clutter in my home directory, I have a lot of files that I have to guess as to where they originated from based on metadata like modification timestamps or permissions, but it would be nice to see something like “~/.config was created by some-tool”.
A general tagging mechanism, reasonably supported across filesystems , would be great to have. Not only for media collections. It's not easy to implement nicely, though.
Oddly I feel completely the opposite about this topic. I think dot files in your home directory are exactly the way to go. Using the XDG standard leaves you with whatever the distro decides is the correct location for these files. While their recommendation is all in the home directory, I wouldn't put it past some of these distro developers to make some crazy /var/users/{uid}/config directory. This is important when…
Yeah, when I got to this: To those of you reading this: I beg you. Avoid creating files or directories of any kind in your user's $HOME directory in order to store your configuration or data. My immediate response was pretty much "where the hell else should they put them then?" What exactly else is the /home dir even for otherwise? The purpose of home is for user-level persistent files. Giving it access to something…