Hard vs Sym link

[Maaz]

Gurus
Share your knowledge, is there any PRACTICAL usage of Hard links ?
In a day-to-day administrative task do you guys ever found usage of hard link as a choice ?

Regards
Maaz

[Alexander Chuzhoy · Accepted solution]

"The reason why hard links are sometimes used in preference to symbolic links is that some programs are not fooled by a symbolic link: if you, say, have a script that uses cp to copy a file, it will copy the symbolic link instead of the file it points to14.1. A hard link however will always be seen as a real file. "

[Ivan Ferreira]

I had no need to use hard links in my day to day taks.

There are some "special" things that you could do with hard links, but these things are not common.

For example, I remember somebody here asking, how to avoid the change of the inode number when a file is edited? The problem was, the editor create a temp file, delete the old file, and then move the temp file as a new file. Increasing the link count for the file with a hard link solved the problem for this user.

[Steven Schweda]

A hard link is simply one more directory
entry (name, path) for a file, just like the
first one.

It's more firmly attacted to the file than a
symbolic link. For example:

td176> echo xxx > file

td176> ln file hlink

td176> ln -s file slink

td176> ls -l
total 16
-rw-rw-rw- 2 antinode 513 4 Apr 1 10:02 file
-rw-rw-rw- 2 antinode 513 4 Apr 1 10:02 hlink
lrwxrwxrwx 1 antinode 513 4 Apr 1 10:02 slink -> file

td176> cat hlink
xxx

td176> cat slink
xxx

td176> mv file elsewhere

td176> cat hlink
xxx

td176> cat slink
cat: Cannot open slink: No such file or directory


Sometimes you may want one behavior. Other
times you may want the other behavior.

Saving a file from being deleted by some
program was the last thing I used a hard link
for, too.

Knowing nothing, I'd assume that a hard link
uses slightly less storage than a symbolic
link. (No link text to store.)

[Heironimus]

I've found hard links to be most useful on NFS servers. Symlinks on an NFS mount still just point to a path and they're resolved on the client, not on the server. If your paths aren't exactly the same on every machine a hard link might work where a symlink fails. You'll see this problem if you use absolute paths on your symlinks, have symlinks that point outside your exported path, or mount subdirectories of the share instead of the root.

For example, the Red Hat Enterprise Linux installer will mount the full path down to the source directory when you install from NFS. That prevents you from putting common files for different release levels in a single place and symlinking them in to the appropriate locations. However, hard links work fine and you still only have one copy of each file using real disk space.

[James R. Ferguson]

Hi:

HP-UX's LVM commands make a rather clever use of hard links.

Every command has a unique name, but of course, as hard links, they actually represent the same code. When the binary is executed it can evaluate the *name* of the file that invoked it and perform the appropriate operation.

The single letters used for switches can server different functional purposes without confusion and arguments can be added or subtracted without complication.

An alternative approach would be to use a common binary but pass an argument that would define the function to perform -- not nearly as clever in my opinion.

Regards!

...JRF...

[Heironimus]

I like doing that for closely-related commands that share most of their code, but it works with both hard and symbolic links. argv[0] or $0 will have the called name either way.

[Dennis Handly]

It's 6 of 1 or 1/2 dozen of another. You can do somethings with hardlinks you can't with softlinks. Steven mentioned keeping files from being deleted. I do that for some important files. You can also use hardlinks to increment the inode count so you can move busy executables aside, at least on HP-UX.

As JRF says, I use hardlinks to deliver multiple compiler drivers. And the same for the man pages. Unfortunately I have to deliver them all on patches, where a symlink would be permanent and only delivered once.

Softlinks links are handy for directories if you want to move them to other filesystems.

[skt_skt]

In HP-UX the permission(777) of softlink does not matter and operation tried would be dealt/hanlded with the permission of the real file.

But i have a contracdiction here in Linux(RHEL AS) if the soft link file is 777 and if a dd operation is performed can over ride the permission of the real file.

Let us know if any one has a chance to test that behavour!!

[Heironimus]

On RHEL4 the permissions work exactly as they should when I try to dd to a symlink. Access is based on the target file, the link permissions are irrelevant.