I've used hard links in the past, but they seem to make a bit of a mess of things...
When is the proper time to use Hard links? What are the best practices for when and where to use hard linking?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
Hard-links can be very useful when you want to have the same contents (and same permissions!) in several files on the same filesystem.
Take for example a package manager, that creates a /usr/share/doc/$packagename directory for each package that is installed and inside that directory a file called LICENSE with the license information of the package. Many packages on a typical Linux system are GPL licensed, so instead of having 200 copies of the GPL on the filesystem there could be only one copy and 199 links.
Distributed version control systems copy the whole repository on clone, there is no checkout like in svn. If several clones of the same repository are on the same filesystem they can share part of the (immutable) files by using hard links (git does this, and darcs too IIRC).
Many backup solutions also use hardlinks, like rsnapshot and backuppc.
The best use I've seen of hardlinks is with rsnapshot.
If you want to achieve, that the file is removed only, when all hard links are removed.
Setting up honeypots with circular links in the file system hierarchy, so an intruder's "find" runs forever.
My users got an folder ~/remote_access with amongst others windows winscp.exe in it. This binary is a hardlink.
So if there comes a new version, I just copy it to my home and all users have the new version ready to copy to their usb stick. It`s like a poor mans automatic software upgrade ;-)
I have a web server where users are only allowed FTP-access (i.e. not SSH) and chroot-ed to their home directory for security purposes. I hardlink the specific file containing their Apache VirtualHost definitions into their home directory so that they can read it i.e. they have visibility into the parts of the config that are relevant to them. This way I don't need to give them access to
/etc/apache (or other parts of the filesystem).
Linux vserver also can use it as a deduplication strategy. You can generally use a hardlink across the boundaries of a chroot, unlike a symlink - but do not forget that whatever manages to change the content of the file also does so outside the chroot, and in the worst case into another chroot. IIRC vserver uses a COW mechanism on top of it...