NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/linux/22435

Text File | 1993-01-02 | 2.7 KB | 61 lines

Newsgroups: comp.os.linux
Path: sparky!uunet!elroy.jpl.nasa.gov!ucla-cs!twinsun!junio
From: [e-mail] (Jun Hamano)
Subject: Re: A discipline for packages
In-Reply-To: [e-mail]'s message of Sat, 2 Jan 1993 05:57:44 GMT
Message-ID: <bk^[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: shadow
Organization: Twin Sun, Inc. (El Segundo CA)
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Date: Sat, 2 Jan 1993 09:44:24 GMT
Lines: 44

   why is a soft link that uses maybe an inode worse than a hard link that
   uses real disk space, right ?

Though the reason original poster stated that a symbolic link is
a system administrators nightmare is _not_ diskspace concern, a
symbolic link is worse than a hard link in that aspect, too.  In
traditional implementation of symbolic link and hard link in
UNIX, which I believe linux also uses, a symbolic link uses a
directory entry storing an inode, and the inode points at a
single block (in minix fs linux uses, it's 1K) to store the name
of the target file it is pointing at.  A hard link uses only one
directory entry and shares the same inode the target file is
using.  The data blocks are shard, of course, because they are
using the same inode.  There was an interesting discussion in
comp.os.bsd newsgroup a couple of weeks back, suggesting that a
pathname shorter than 60 or so bytes (the length of the space
allocated in an inode that is usually used for storing block
pointers) could be stored in an inode itself without wasting a
whole block; I thought it would be a reasonable thing to do.

Two more important reasons why a symbolic link is a nightmare
are:

(1) with a hard link, you can tell a file is pointed at by
somebody else by looking at the target file, but a target file a
symbolic file is pointing at doesn't know it is pointed at by
somebody else at all; after removing such a file, the symbolic
link pointing to it becomes an useless dangling link (it points
to an non-existent file).  With a hard link, you don't have this
problem; the original disappears from the directory structure,
but the file itself is not removed as long as any hard link is
pointing to it.

(2) with symbolic links, you have to be very careful not to tar
off symbolic links without tarring the originals they are
pointing at (unless the targets are well-known places in the
directory tree); otherwise, when you unpack the tar archive, you
will have only pointers and no real data ---useless dangling link
again.
--
      |
   __-+-__      Jun Hamano
_-+ (|o|) +-_   [e-mail]
  !   .   !