Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dotfile madness

0x46.net

Post reply on HN
Print view View original

71–80 of 534 posts

Re: Dotfile madness

#71

Post by netsec_burn »

nine_k wrote: post #60
saagarjha wrote: post #4

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.

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.

Re: Dotfile madness

#72

Post by nine_k »

netsec_burn wrote: post #71
nine_k wrote: post #60

Earlier quoted context omitted.

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.

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.

Adding an interface to access the tag store won't be very hard.

It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.

Re: Dotfile madness

#73

Post by tempay »

bauerd wrote: post #50
withinboredom wrote: post #26

Earlier quoted context omitted.

Not everyone has a large $HOME directory. It might be mounted on a 128mb thumbdrive for all you know.

Esoteric setups aside, I'd be interested to hear about problems that people actually have encountered with this convention.

My partner has to manage having a 500MB quota on their home directory at work. A couple of times a month something decides to dump 300+ MB of data in there and break everything.

Re: Dotfile madness

#74

Post by sowbug »

bauerd wrote: post #21

I don't get the problem. Why bother where dotfiles are written to? GUI file managers and userland tools hide them by default. What would I gain by having them written outside of $HOME?

It avoids the realization that you have been paying AWS to back up ~/.cache and ~/.local for the last 6 months.

Re: Dotfile madness

#75

Post by netsec_burn »

nine_k wrote: post #72
netsec_burn wrote: post #71

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.

Adding an interface to access the tag store won't be very hard. It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.

Sounds like you might need to hook rename() if you'd like to add that feature too, but I would still say it's straightforward.

Re: Dotfile madness

#76

Post by yjftsjthsd-h »

kondor6c wrote: post #30
fxfan wrote: post #16

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…

Why not _shame_ openssh? Or vim? Or emacs? I would advise not calling for shame on any of these projects because they have a pattern to support that has been in place longer than the XDG standard has been in place. You can change gnupg's home dir, but it would break a lot of currently functional setups if it just moved.

I'm personally willing to give SSH a partial pass because I feel like having it separate makes it easier to reason about from a security perspective (this would also apply to GPG).

For vim... yeah, AFAIK "vim" does that, but neovim uses ~/.config/nvim :)

And to your general point... yes, many of these programs predate XDG. I happily support keeping them backwards compatible (which should be easy; checking multiple places in order is a time-honored tradition). But I honestly don't think this was a good idea even decades ago, and "we've always done it this way" is a terrible reason to not even support a newer, cleaner approach. Again, there's no reason to break existing systems; just support an additional location, probably make it the default, and everyone will be happy.

Re: Dotfile madness

#77

Post by fxfan »

Jaruzel wrote: post #2

This isn't just a Linux problem. In Windows, the users /documents folder is polluted in exactly the same way these days.

The post isn't about the problem of cluttering- it's about the problem of programs not caring to adopt a super simple solution

Re: Dotfile madness

#78

Post by sneak »

Would exporting HOME to something else (eg the xdg root/appname) prior to invoking programs solve this problem for most apps without code changes?

Re: Dotfile madness

#79

Post by kazinator »

saagarjha wrote: post #4

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”.

Apple's Macintosh did this in 1984. Files were tagged with 32 bit codes: one for the "creator" (the associated app) and one for the type. These were often made up out of readable characters: a so called "fourcc" (four character code). The "fourcc" persists in cross-platform media formats.

Re: Dotfile madness

#80

Post by sneak »

nine_k wrote: post #72
netsec_burn wrote: post #71

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.

Adding an interface to access the tag store won't be very hard. It would be harder to make it so that all the tag-oblivious programs, like mv or vi, to say nothing of rsync, would preserve the attributes when moving or modifying a file.

Sidecar files might work, and would also be filesystem-portable.
Post reply on HN