Live data from Hacker News

Dotfile madness

0x46.net

91–100 of 534 posts

Re: Dotfile madness

#91

Earlier quoted context omitted.

I think saagarjha's point was that an even simpler standard would be for the creating application to use file metadata to annotate the files. And a simpler standard is generally more likely to be followed, especially if it's unilateral. This doesn't help with installation, obviously, but it helps with cleanup.

The classic MacOS had exactly this concept: Creator Code[0], similar to the Type Code[1] but storing a file's creator rather than its "mimetype". [0] https://en.wikipedia.org/wiki/Creator_code [1] https://en.wikipedia.org/wiki/Type_code

Good point, I had almost forgotten about those!

Re: Dotfile madness

#92
post #2

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

Also on macOS, where [~]/Library/ApplicationSupport is the designed and recommended place to store config files, logs, preferences and all kinds of persistent data, the home directory still gets cluttered. It's a laziness issue, it won't be solved solely by making is easier to access the right locations on each system/platform, but that would be a step in the right direction.

I would honestly like to blacklist my home folder. Do you want to create a new file/folder? I am notified with a popup and if you ask to often I am gonna stop using that. Not really workable but one can still dream...

Re: Dotfile madness

#93
post #86

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.

You're right. I can see anything like scripts getting difficult. It wouldn't work for all use cases.

Re: Dotfile madness

#94
post #48

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

MacOS stores this for files I download through a browser. "Get Info" has a "Where from" property: http://osxdaily.com/2010/10/12/find-out-where-a-file-was-dow...

Windows does something similar with Alternate Data Streams [0]

[0] https://textslashplain.com/2016/04/04/downloads-and-the-mark...

Re: Dotfile madness

#96
post #86

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.

Have you seen actual programs (not shell scripts) that do that? I've heard of code smells, but that's a programmer smell with there.

Re: Dotfile madness

#97
post #88

Earlier quoted context omitted.

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.

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…

Thanks for teaching me this! I wasn't aware. So, the original xattr (and the program that created it) would be deleted and replaced by vi for example. Still technically right, but I'm unsure how you'd keep a history.

Re: Dotfile madness

#98
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.

Why such a hack? This is a solved problem already. Try Linux audit API. You can set it up for tracking various actions, and you'll get a log with all the information including a process name.

https://linux-audit.com/configuring-and-auditing-linux-syste...

Re: Dotfile madness

#99
post #86

Earlier quoted context omitted.

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.

Have you seen actual programs (not shell scripts) that do that? I've heard of code smells, but that's a programmer smell with there.

I think touch is a generic example, but not a practical one. The idea is that program A can launch program B, and you'd have to recursively search for the parent. But it's not easy to find which parent is the true owner, maybe an exception can be made for init but shells can't have that exception as they are sometimes the owner.

Re: Dotfile madness

#100
post #67

Earlier quoted context omitted.

The other way-- and I'm sorry for how smug this sounds-- is to just not litter in your own home directory without cleaning it up. How about the other way is I’ll just stop using your product/service/business that doesn’t respect my machine?

That's my point exactly. Most of these programs have command line flags you can pass to indicate the configuration file that should be used. Doing that, and then by default putting my configuration in the most reasonable place for it--a dotfile-- is, in my opinion, the most respectful way a programmer can treat someone's machine. Not to mention that most of these are free and open source, so building according to con…

you could check if ~/.local/share and ~/.config exist. also there is a difference between files that the user is supposed to interact with and inner configuration of random apps. ~/.ssh is fine, I need to look at it for many .emacs.d is fine as is something you are expected to edit manually, but I don't even know what some of these are: .aspell.en.prepl .dmrc .dropbox .dropbox-dist .gtkrc-2.0 .joe_state .oracle_jre_usage .pdfsam .pylint.d snap .texlive2016 .wget-hsts .vscode .xdvirc

This is from a fresh install 3 months ago, do I need 2 dot-folders for dropbox?

Post reply on HN