[CLUE-Cert] Answers to some of the questions from last meeting

John Kottal jlkottal at americanisp.net
Fri Dec 1 07:57:35 MST 2000


This may answer some of the questions from Wednesday nights meeting:

Links (This if from Aeleen Fritsch's Essential System Administration,
and I think it will also apply to Linux):

    A hard link associates two (or more) filenames with the same inode.
Hard links all share the same disk data blocks while functioning as
independent directory entries. Hard links may not span physical devices.

    Symbolic (soft) links are pointer files that name another file
elsewhere in the filesystem. A symbolic link is a file which points to
another pathname in the filesystem. Symbolic links may span physical
devices.

    The two types of links behave similarly, but are not identical. As
an example, consider a file INDEX, to which there is a hard link HLINK
and a symbolic link SLINK. Lisitng the contents of any of them with a
command like cat will result in the same output. For both INDEX and
HLINK, the disk contents pointed to by the addresses in their common
inode will be accessed and displayed. For SLINK, the disk contents
referenced by the address in its inode will point to the pathname for
INDEX; when it is followed, INDEX's inode will be accessed next, and
finally its data blocks will be displayed.

    In directory listings, HLINK will be indistinguishable from INDEX.
Changes made to either file will affect both of them, since they share
the same disk blocks. However, moving either file with them mv command
will not affect the other one, since moving a file only involves
altering a directory entry (keep in mind that pathnames are not stored
in the inode). Similarly, deleting INDEX will not affect HLINK, which
will still point to the same inode. If a new file in the current
directory named INDEX is subsequently created, there will be no
connection between it and HLINK because when the new file is created, it
will be assigned a free inode. Although they are initially created via
an existing file, hard links are linked only to an inode, not to the
other file. In fact, all regular files are technically hard links.

    In contrast, as symbolic link SLINK to index will behave
differently. The symbolic link appears as a separate entry in the
directory lisitngs, marked as a link with an "l" as the first character
in the mode string. Symbolic links are always very small files while
every hard link to a given file is exactly the same size (HLINK is
naturally the same length as index).

    Changes made by referencing either the real filename or the symbolic
link will affect the contents of INDEX. Deleting INDEX will also break
access via the symbolic link; SLINK will point nowhere. But if another
file INDEX is subsequently recreated, SLINK will once again be linked to
it. Deleting SLINK will have no effect on INDEX.



Types of Files

    Fritsch gives the following as file types under UNIX: regular files,
directories, special files (character and block files), links, sockets,
and named pipes.

    Nemeth (UNIX System Administration Handbook (Third edition), aka
"The Purple Book") gives the following:  regular files, directories,
character device files, block device files, UNIX domain sockets, named
pipes (FIFOs), symbolic links.



Named pipes vs pipes

    From Steven's Advanced Programming in the UNIX Environment (APUE):

        Pipes are the oldest form of UNIX IPC (interprocess
communication). They have two limitations:

            1. They are only half-duplex. Data flows only in one
direction.
            2. They can be used only between processes that have a
common ancestor.

    Stream pipes get around the first limitation, and FIFOs and named
stream pipes get around the second limitation. Despite these
limitations, half-duplex pipes are still the most commonly used form of
IPC.

    A named pipe (FIFO) is a special type of pipe that exists as a name
in the filesystem, but behaves like an unamed pipe. Named pipes allow
unrelated processes to exchange data. (Stones and Matthew, Beginning
Linux Programming).

John Kottal



More information about the clue-cert mailing list