Difference Between a Symbolic Link and a Hard Link(toolhub.tech)
toolhub.tech
Difference Between a Symbolic Link and a Hard Link
https://toolhub.tech/blog/Difference-between-Symbolic-Link-and-Hard-Link/
14 comments
Good explanation and same for me.
I came to that realization when I needed to delete a file and the function call to use was named `unlink`.
I came to that realization when I needed to delete a file and the function call to use was named `unlink`.
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.
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.
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)
(Or at least I think so - not a Linux expert here)
What system can you hardlink a directory? At least on macOS and FreeBSD the man pages explicitly state that hard links can only be created on files.
Nit about macOS: HFS+ supports hard links to directories (added in 10.5 to support Time Machine), but APFS does not.
Interesting, thanks for the information. I had thought it was the same with HFS but guess it's been some time since I used it...
I believe you can do it on Windows.
Windows does not allow hardlinks to directories, but it does have the concept of junction points.
https://learn.microsoft.com/en-us/sysinternals/downloads/jun...
https://learn.microsoft.com/en-us/sysinternals/downloads/jun...
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.
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.
It's not a POSIX standard, but most implementations of find support "-samefile" as a more straightforward shortcut, like:
find / -samefile /path/to/some/hard/link
find / -samefile /path/to/some/hard/link
Feels like this article should also mention reflinks.
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.