Hard/Symbolic Links [was: Re: r7347]

Baho Utot baho-utot at columbus.rr.com
Fri Apr 11 15:35:18 PDT 2008


On Fri, 2008-04-11 at 11:30 -0500, Bruce Dubbs wrote:
> Randy McMurchy wrote:
> > Christian Wurst wrote these words on 04/11/08 06:50 CST:
> > 
> >> I'd say making the book more consistent (in itself, but also with LFS)
> >> is a reason too. If we do symlinks here (vim for instance) and
> >> hardlinks there (ed), without a clear reason why, it might confuse
> >> readers. If we differ from a standard way of doing things there should
> >> be a reason - and it should be explained in the book why it is done
> >> different in this case.
> >> If my explanation about the differences of hard and symlinks is
> >> correct, I can really live with both. But we really should have a
> >> standard way to do it.
> > 
> > Thanks for the input Christian! I'm also hoping Ag will comment,
> > especially about "unnecessary" hard links.
> > 
> > As far as your comment about "standard way to do it", I want the
> > standard way to be: leave it as the package author wrote it, unless
> > there is a problem with how he did it, or we can make it significantly
> > better by changing it.
> > 
> > Changing a hard link to a soft link doesn't fit in either of those
> > categories.
> 
> I agree with Randy's policy.
> 
> A couple of notes about hard vs soft (symbolic) links.  All hard links must be 
> on the same file system.  This is not true of soft links.  Hard links means that 
> there can never be a "dead" or non-existing link target.
> 
> Second, you can not have a hard link to a directory.  It has the potential to 
> create loops in the file system that would cause havoc.  Of course, you can have 
> a soft link to a directory.
> 
> Third, symbolic links take up slightly more disk space than a hard link.  A hard 
> link is only an inode.  The soft link uses an inode and an additional block with 
> the path to the target files.
> 
> Fourth, directories contain hard links to each file contained in that directory.
> 
> Fifth, hard links can have different permissions and ownership.  That does not 
> really make sense for symbolic links, even though it is possible.
> 
>    -- Bruce

If I may offer my 2 pesos on this

Hard Link

When multiple file names in the file system refer to a single inode ,
the files are called hard links to one other.  All file names must
reside in the same physical file system.  When a file has multiple hard
links, each of those file names is an exact peer, and there is no way to
tell which file name was originally used.  Removing one hard link does
not remove the file from the device, it stays until all the links to it
are removed.  

Symbolic Link

Are more flexible than hard links, but don't share the peer
relationships.  Hard links share an inode, symlinks point to other file
names.  If the destination file is removed the result is a dangling
link. Can be use between sub directories and cross physical file system
boundaries.  It still may be true (I have not checked) that chown()
lstat() readlink() rename() and unlink() system calls (I am talking C
here) do not follow symbolic links.

FWIW is think leaving the hard/sym link is best kept like the author of
the package.

-- 
Tayo'y Mga Pinoy




More information about the blfs-book mailing list