What made it click for me mentally was this thought: there's no such thing as a hard link. Or alternatively, every file is a hard link.
Files don't have names. At least, they don't have names for themselves. Instead, they have unique ids (i-node numbers).
But obviously we use names for files, which happens because a directory can give a name to a file. However, the name is just that directory's name for the file.
There is no rule against multiple directories each giving their own name to a file, and there is no rule against one directory giving multiple names to a file.
So a "hard link" is not some special, different type of thing. It's another instance of the same type of thing that happened when you first created the file. So it's clearer (to me) to either not think of any of them as hard links or to think of all of them as hard links.
HP used to have a thing called Context Dependent Files (maybe still does?) that was part of their discless clustering. It was like a symlink, but instead of being a file that contains the name of another path, it was a directory of files. The files were named things like system architecture (m68k), and hostname, and the kernel would search for a match using some precedence rules, then treat it like a symlink.
So on your NFS mount you could have different files for, say, /bin/ls, based on architecture, or /etc/hostname that differed by the name of the host.
I always thought CDFs were pretty clever, but they never seemed to gain any traction.
Back in the old days, I had some sort of arcane chroot setup for FTP for this website. I used a hard link to resolve everything. Well, like a year into it, I forgot that I used a hard link. I needed to update a few things, so I just rm’d the supposed sym link and nuked the entire site.
Learned a hard lesson about backups that day. I did have some, but of course we still lost some data.
Huh, if you had hard links, won't the second file pointing to the data on the disk still exist somewhere else? I.e. the file would still be intact? And the disk space wouldn't be marked free/be in danger of being overwritten?
If it was a hard link to a directory, rm -r could've removed all the files from it first, before removing the directory itself. This would remove everything from the original dir.
(Or at least I think so - not a Linux expert here)
It's also worth noting that hard links are "harder" to view and find compared to symbolic links (symlinks) and are primarily used for administrative instead of user purposes. Modern terminals display symlinks with colour, the -F option to ls appends @ to symlinks, and the -l option displays the target.
Hard links are only indicated by a link count >1 for files, but to find them, you must search by inode number (since they all share the same inode number) - e.g., ls -i to list inode numbers, and find / -inum 1234 (for inode 1234) to find them on the same filesystem.
Files don't have names. At least, they don't have names for themselves. Instead, they have unique ids (i-node numbers).
But obviously we use names for files, which happens because a directory can give a name to a file. However, the name is just that directory's name for the file.
There is no rule against multiple directories each giving their own name to a file, and there is no rule against one directory giving multiple names to a file.
So a "hard link" is not some special, different type of thing. It's another instance of the same type of thing that happened when you first created the file. So it's clearer (to me) to either not think of any of them as hard links or to think of all of them as hard links.