Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Hard links, necessary evil?
Message-ID: <53680@nigel.ee.udel.edu>
Date: 15 May 91 13:08:42 GMT
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 39
Nntp-Posting-Host: snow-white.ee.udel.edu


I've been trying to figure out what hard links are good for.  I've been able
to come up with a few uses as used under UNIX, but I don't think it's worth
the hassle of handling hard links in tar, fsck, etc given the benefits. What
I'm looking for is feedback on whether or not, were *you* to write a new OS,
you would include hard links and why.

The benefits of hard links that I perceive (and have been locally pointed out)
are these:

1) compress/uncompress/zcat are all one program.  SOLUTION: add a flag, 
   possibly allowing the shell to translate "uncompress" into "compress -d"
   if desired. This info could be stored in a way as to make it easy
   to access, or as symbolic links.
2) . and .. become simple to implement once hard links are available.
   SOLUTION: handle . and .. lexically (i.e., in the file name parser rather
   than in the file system, much as ~user/.... is/should be handled). 
   Most programs which deal with directories already do this: tar and ls 
   don't follow .. for example.
3) Allows same file to appear multiple places in the namespace. SOLUTION:
   use full path names for distant files, or use symbolic links or logical
   assignments.
4) Allows multiple people to access a file, with the file remaining until
   all have deleted it.  SOLUTION: Maybe add a "link-count" without 
   actually allowing links.
5) The semantics of "mv" become obvious and failsafe. SOLUTION: make
   "rename" a primitive OS operation.

My main objection to hard links is the complexity of managing several names
for the same information. For example, tar must keep track of which i-nodes it
has seen so as to save only one copy of a multiply-linked file. Hence, I don't
object to symbolic links, reference counts on files, and so on.

Just wondering about other's thoughts on the subject...

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+