Very Computer

HI All,

I have a question regarding hard/soft link. in unix/linux file system, I
just know some basic diffirent between hard/soft link. I check system like
solaris/redhat/bsd. the solaris used lots of hard link, the most is 27 hard
links.
Who can tell me some details what is real advantage using hardlink.

Thanks

Jaff

Hard links don't use any storage (other than the directory entry),
whereas symbolic links are files themselves therefore need some storage
of their own.  Some people/software prefer symbolic links because it's
easier to see the relations and thus make changes later.

Yuan Liu

Hardlinks allow the same data to have two seperate names, without taking
up the space of having two identical files.  To free up the space taken
by the data, all of the links to it need to be removed.  Symbolic links
("soft links") point to one filename; the symbolic links don't need to
be deleted for the file (and it's data) to be deleted.  So, it's
possible for "dead" symbolic links to be created, while hard links will
always point to data.

Basically, the main advantage of hard links is that they allow one piece
of data to have more than one name.  Softlinks are more like Windows
"shortcuts", they point to another file name, not another piece of data.

--
+ http://www.not-real.org/~nick                                   +
+ How valuable is my contribution? Share your feedback at Affero: +
+ http://svcs.affero.net/rm.php?r=nick                            +

I can tell you a disadvantage.  Hard links won't work over a network (NFS).  Soft links will.

dawson li graced us by uttering:

Quote:> I have a question regarding hard/soft link. in unix/linux file system,
> I just know some basic diffirent between hard/soft link. I check
> system like solaris/redhat/bsd. the solaris used lots of hard link,
> the most is 27 hard links.

> Who can tell me some details what is real advantage using hardlink.

Other posts cover some well-known advantages of hardlinks, but there are
a few somewhat obscure quirks with them as well.

First, hardlinks can only exist on the same filesystem.  That is, if you
have one disk mounted as / (root fs) and a separate disk mounted on
/usr, then you would not be able to hardlink /usr/bin/an_app to
/bin/an_app because they're on different physical disks.  This is one
instance where symlinks (soft links) may be a better option.

Second, if you are editing a file which is hardlinked to two separate
locations, there is at least one potential problem.  If your editor
_opens_, _modifies_, and then _saves_ the file, all is well.

OTOH, if the editor merely _opens_, _reads_, and then _writes_ a
completely separate file, you've lost your hardlink and you now have two
separate files; changes made to one will _not_ be reflected in the
other.  Symlinks will (most likely) not have this problem.

HTH,
Tim Hammerquist
--
"Sometimes these hairstyles are exaggerated beyond the laws of physics."
    -- Unknown narrator on Anime

Very interesting point.  Can you name any specific editor that behaves this
way?

Emacs does behave this way (at least, some versions do in the default
configuration). And it's a reasonable strategy of many editors:
When saving a file, write it with a different (temporary) name, then do
a rename(2) to the original name. That way, the switch from the old to
the new version is atomic: any process reading the file will either see
the old, or the new version, but never some intermediate state, and
should the editor or the system crash while writing, the file will remain
unchanged.

vi (and some clones) tends to _not_ do it this way, and you can get
funny errors if you make the mistake of using vi to edit a shell script
while it is running.

Regards,

Timo Felbinger

--

Quantum Physics Group    http://www.quantum.physik.uni-potsdam.de
Institut fuer Physik     Tel: +49 331 977 1793      Fax: -1767
Universitaet Potsdam, Germany

message

otsdam.de...

Quote:> Quantum Physics Group    http://www.quantum.physik.uni-potsdam.de
> Institut fuer Physik     Tel: +49 331 977 1793      Fax: -1767
> Universitaet Potsdam, Germany

Excellent quirks Timo. I am now performing some horrible experiments...
heh..

Sean

OK, I'll give it a try...  (caution, some lines here exceed 100 chars width)

    Unix files consist of two parts: the data part and the filename part

    The data part is associated with something called an 'inode'. The inode
    carries the map of where the data is, and the permissions, etc for the
    data.

                                .---------------> ! data ! ! data ! etc
                               /                  +------+ !------+
         ! permbits, etc ! data addresses !
         +------------inode---------------+

    The filename part carries a name and an associated inode number.

                          .--------------> ! permbits, etc ! addresses !
                         /                 +---------inode-------------+
         ! filename ! inode # !
         +--------------------+

    More than one filename can reference the same inode number; these files are
    said to be 'hard linked' together.

         ! filename ! inode # !
         +--------------------+
                         \
                          >--------------> ! permbits, etc ! addresses !
                         /                 +---------inode-------------+
         ! othername ! inode # !
         +---------------------+

    OTOH, there's a special file type, who's data part carries a path to
    another file. Since it is a special file, the OS recognizes the data as a
    path, and redirects opens, reads and writes so that, instead of accessing
    the data within the special file, they access the data in the file _named_
    by the data in the special file. This special file is called a 'soft link'.

         ! filename ! inode # !
         +--------------------+
                         \
                          .-------> ! permbits, etc ! addresses !
                                    +---------inode-------------+
                                                      /
                                                      /
                                                     /
     .----------------------------------------------'
    !
     '-->  !"/path/to/some/other/file"!
           +---------data-------------+
                   /                      |
     .~ ~ ~ ~ ~ ~ ~                       |-- (redirected at open() time)
    :                                     |
     '~~> ! filename ! inode # !
          +--------------------+
                          \
                           '------------> ! permbits, etc ! addresses !
                                          +---------inode-------------+
                                                             /
                                                            /
      .----------------------------------------------------'
      !
      '->  ! data !  ! data ! etc.
           +------+  +------+

    Now, the filename part of the file is stored in a special file of it's own
    along with the filename parts of other files; this special file is called a
    directory. The directory, as a file, is just an array of filename parts of
    other files.

    When a directory is built, it is initially populated with the filename parts
    of two special files: the '.' and '..' files. The filename part for the '.'
    file is populated with the inode# of the directory file in which the entry
    has been made. '.' is a hardlink to the file that implements the current
    directory.

    The filename part for the '..' file is populated with the inode# of the
    directory file that contains the filename part of the current directory
    file. '..' is a hardlink to the file that implements the immediate parent
    of the current directory.

    The 'ln' command knows how to build hardlinks and softlinks; the 'mkdir'
    command knows how to build directories (the OS takes care of the hardlinks).

    There are restrictions on what can be hardlinked (both links must reside on
    the same filesystem, the source file must exist, etc.) that are not
    applicable to softlinks (source and target can be on seperate file systems,
    source does not have to exist, etc.). OTOH, softlinks have other
    restrictions not shared by hardlinks (additional I/O necessary to complete
    file access, additional storage taken up by softlink file's data, etc.)

    In other words, there's tradeoffs with each.

    Now, let's demonstrate some of this...

    Let's start off with an empty directory, and create a file in it

       ~/directory $ ls -lia
       total 3
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:16 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..

       ~/directory $ echo "This is a file" >basic.file

       ~/directory $ ls -lia
       total 4
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:17 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..
         73478 -rw-r--r--   1 lpitcher users          15 Mar 11 20:17 basic.file

       ~/directory $ cat basic.file
       This is a file

    Now, let's make a hardlink to the file

       ~/directory $ ln basic.file hardlink.file

       ~/directory $ ls -lia
       total 5
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
         73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 basic.file
         73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 hardlink.file

       ~/directory $ cat hardlink.file
       This is a file

    We see that
     a) hardlink.file shares the same inode (73478) as basic.file
     b) hardlink.file shares the same data as basic.file
    If we change the permissions on basic.file

       ~/directory $ chmod a+w basic.file

       ~/directory $ ls -lia
       total 5
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
         73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
         73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file

    then the same permissions change on hardlink.file.
    The two files (basic.file and hardlink.file) share the same inode and data,
    but have different file names.

    Let's now make a softlink to the original file

       ~/directory $ ln -s basic.file softlink.file

       ~/directory $ ls -lia
       total 5
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:24 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
         73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
         73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file
         73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

       ~/directory $ cat softlink.file
       This is a file

    Here, we see that, although softlink.file accesses the same data as
    basic.file and hardlink.file, it does not share the same inode (73479 vs
    73478), nor does it exhibit the same file permissions. It does show a new
    permission bit: the 'l' (softlink) bit.

    If we delete basic.file

       ~/directory $ rm basic.file

       ~/directory $ ls -lia
       total 4
         73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:27 .
         91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
         73478 -rw-rw-rw-   1 lpitcher users          15 Mar 11 20:17 hardlink.file
         73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

    then we loose the ability to access the linked data through the softlink

       ~/directory $ cat softlink.file
       cat: softlink.file: No such file or directory

    However, we still have access to the original data through the hardlink

       ~/directory $ cat hardlink.file
       This is a file

    You will notice that when we deleted the original file, the hardlink didn't
    vanish. Similarly, if we had deleted the softlink, the original file wouldn't
    have vanished.

    A further note with respect to hardlink files:

    When deleting files, the data part isn't disposed of until all the filename
    parts have been deleted. There's a count in the inode that indicates how
    many filenames point to this file, and that count is decremented by 1 each
    time one of those filenames is deleted. When the count makes it to zero,
    the inode and it's associated data are deleted.

    Bye the way, the count also reflects how many times the file has been opened
    without being closed (in other words, how many references to the file are
    still active). This has some ramifications that aren't obvious at first:
    you can delete a file so that no "filename" part points to the inode,
    without releasing the space for the data part of the file, because the file
    is still open.

    Have you ever found yourself in this position: you notice that
    /var/log/messages (or some other syslog-owned file) has grown too big, and
    you
      rm /var/log/messages
      touch /var/log/messages
    to reclaim the space, but the used space doesn't reappear? This is because,
    although you've deleted the filename part, there's a process that's got the
    data part open still (syslogd), and the OS won't release the space for the
    data until the process closes it. In order to complete your space
    reclamation, you have to
      kill -SIGHUP `cat /var/run/syslogd.pid`
    to get syslogd to close and reopen the file

    You can use this to your advantage in programs: have you ever wondered how
    you could
...

read more »