Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!lll-crg!rutgers!topaz!ll-xn!mit-amt!mit-eddie!mit-trillian!rlk
From: rlk@mit-trillian.MIT.EDU (Robert L Krawitz)
Newsgroups: net.unix
Subject: Re: Are links as useful as they could be?
Message-ID: <1209@mit-trillian.MIT.EDU>
Date: Sun, 28-Sep-86 15:52:16 EDT
Article-I.D.: mit-tril.1209
Posted: Sun Sep 28 15:52:16 1986
Date-Received: Tue, 30-Sep-86 20:05:34 EDT
Reply-To: rlk@athena.MIT.EDU
Distribution: net
Organization: MIT Project Athena
Lines: 55

First of all, mv does not use link(2) followed by unlink(2).  It uses
rename(2), which is a system call.

Secondly, "all hard links are equal."  Each directory entry is just a
name and a pointer to an inode, and the inode holds the link count.
Link() and unlink() increment and decrement the link count of the
inode.  When this reaches zero, the inode is deallocated and the
storage returned to the free list.  This mechanism allows the use of
links to protect the existence (although not the contents) of precious
files -- just keep a link to the file around somewhere.

It should be obvious why hard links between file systems are
impossible.  A directory entry refers to a certain inode, not to any
filesystem (there is no guarantee that any other filesystem will be
mounted).  The device is implicitly the device that the directory is
in.  Links to directories are not impossible, just forbidden to
non-superusers to reduce the chance of filesystem corruption of the
form of a closed loop unaccessible to the rest of the file system
(fsck does detect this, by the way).  Actually, mkdir(2) does create
links to directories -- after all, . and .. in each directory are
nothing more than links.  On unix systems without the mkdir(2) system
call, a privileged program (mkdir(1)) calls mknod(2) followed by two
calls to link().  This exception is a controlled, safe exception,
since a system call rmdir(2) is needed to unlink a directory, which
takes care of all cleanup.

Restricting all hard links to the same (NOT the "current", which has a
specific meaning) directory would cause far more problems that it
could possibly solve.  First of all, all calls to link() would have to
check that other links to a file were in the same directory, which
would require a search of the whole filesystem.  Secondly, rename()
would have to check similar conditions.  Also, it would weaken the
power of links.

It is true that to find all links to a file you have to search the
entire filesystem.  That's one of the problems with the simple link
concept of unix.  However, all powerful tools have some drawbacks.

The problems for tar and rdist aren't as bad as you suggest.  All that
they have to do is remember which inodes from what filesystems have
already been found.  This could be a bit vector.  Usually the actual
disk partitions are not readable, but in a pinch df -i can be used to
get the number of inodes in each file system (a fixed quantity).

Symbolic links are completely different.  They are pointers to
arbitrary pathnames as opposed to pointers to inodes.  As far as the
filesystem is concerned, they are just a slightly special type of
file.  The only thing special about them is that most system calls
automatically indirect through them (to a certain level to prevent
looping).

Translation:  restricting links would be pointless, difficult to
implement, etc.  The homogeneity of the unix filesystem is one of its
strengths.
-- 
Robert^Z