I drafted a longer reply which got lost in a browser hiccup.
I find myself much less often surprised by behaviour regarding hard links than by stuff that happens with symbolic links ... so I use hard links more often. I find this difference in perception intriguing.
"I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files [...]"
Er ... except that with a hard link, the link is the file (all links to it are equally "the real file").
I know I can get a link count for a file. Is there any reasonably fast way to locate all other links to a file? I can exec 'find' to search the rest of the filesystem for files with the same inode number, but on any realistically-sized, moderately full hard disk, that's going to be ssslllooowww. (I didn't spot anything likely-looking using "man -k link".)
User interfaces are the parts of design I dread, because I know how much bad or mediocre ones annoy me, and I'm not at all confident that my UI design skills are good enough to meet my own standards. Even, once we get into details like this, a command-line UI.
Better that such decisions are in the hands of someone who recognizes that they're tough, than the responsibility of someone who thinks they're easy because they're unimportant, eh?
(no subject)
I find myself much less often surprised by behaviour regarding hard links than by stuff that happens with symbolic links ... so I use hard links more often. I find this difference in perception intriguing.
"I expect backups to be in cwd, not in the directory of the file I'm editing. So for a hard link to somewhere else, it'd be next to the link, not next to the file. This does seem to lead to a surprising result, however! I think 'best' might be to put the backups next to the original of the files [...]"
Er ... except that with a hard link, the link is the file (all links to it are equally "the real file").
I know I can get a link count for a file. Is there any reasonably fast way to locate all other links to a file? I can exec 'find' to search the rest of the filesystem for files with the same inode number, but on any realistically-sized, moderately full hard disk, that's going to be ssslllooowww. (I didn't spot anything likely-looking using "man -k link".)
User interfaces are the parts of design I dread, because I know how much bad or mediocre ones annoy me, and I'm not at all confident that my UI design skills are good enough to meet my own standards. Even, once we get into details like this, a command-line UI.
Better that such decisions are in the hands of someone who recognizes that they're tough, than the responsibility of someone who thinks they're easy because they're unimportant, eh?