[ILUG] (un)link

[Brian Foster]

  | Date: Mon, 24 Jun 2002 17:33:05 +0100
  | From: Padraig Brady <padraig at antefacto.com>
  | 
  | I just noticed 2 new utilities in gnu fileutils
  | (that contains cp,rm,ln,...), called link and unlink.
  | link basically does what ln does, execpt it just
  | calls link(), and unlink as you'd expect, does what
  | rm does, except it just calls unlink(). To rub
  | salt in the would they're not even links to ln and rm.
  | I asked the fileutils maintainer why these are needed,
  | and he said it was done for posix compliance.

 hum....  POSIX?  sounds more like Spec1170 (at least it does to me).
 but that is neither here nor there....

 historically, I strongly suspect the original reason for these two
 commands dates back to the pre-`fsck' days, when filesystem repair
 was a partly-manual job.  whilst `ncheck', `icheck', and `dcheck'
 (or was it `bcheck'?), when used properly, did fix most problems,
 there were also, as I now recall, several trivial fix-it tools.
 I suspect `/etc/link' and `/etc/unlink' were two of those tools.

 on some systems, and historically, `link' is _not_ the same as ln(1),
 nor is `unlink' the same as rm(1).  the difference is the superuser
 used to be able to create/remove hard links to directories.  (AFAIK,
 this is strictly forbidden on all(?) modern *ix systems.)  the `ln'
 and `rm' commands (and, in some systems, the `mv' command) could not
 be used on directories; the command itself checked and _always_
 disallowed even if the underlying system call would "work".

 the reason link(2)/unlink(2) used to be possible on directories is
 simply because that was how you created/deleted them.  the mkdir(1)
 command used to be essentially:

    mknod("./newdir", mode | S_IFDIR, (dev_t)0);
    link( "./newdir/.",  "./newdir");
    link( "./newdir/..", ".");

 you can guess what rmdir(1) used to be.

 all this has long since been abandoned: it is not atomic, and hence
 causes problems for NFS (e.g.), as well as being a security hole
 (esp.  since both the `mkdir' and `rmdir' commands used to have to
 be setUID-"root"!).  mkdir(2) and rmdir(2) were added originally
 for NFS, obsoleting the above older technique.

 has any script ever used either `link' or `unlink'?  ...not that I
 can recall (excepting corrupt-filesystem-then-test-`fsck' scripts).

 has anyone ever used either in anger?  YES.  I have!  but the reason
 I did is not actually a good reason to have these commands; it is
 more a reason _not_ to....    a junior engineer wanted to replicate
 a directory hierarchy on a filesystem that did not support symbolic
 links.   he got the bright idea of `su'ing and `link'ing the directory
 itself, rather than the usual solution of `find ... | cpio -pl ...'.

 the problem --- and the underlying reason you never hard link to a
 directory --- is it creates loops in the filesystem.  this is not a
 problem for symlinks, since it is easy to count (and so limit) the
 number of links followed (ELOOP).  but a loop built from hard links
 is not easy to detect (esp.? on-the-fly within the kernel)....

 the loop the junior created broke the automated build-and-test with
 a very very strange error from `find'.  as team guru, it was my job
 to fix it.  once I had worked out what had happened, it was easy to
 fix --- `unlink' --- albeit followed by an `fsck' for peace of mind.

cheers,
	-blf-
--
 Innovative, very experienced, Unix and      | Brian Foster    Dublin, Ireland
 Chorus (embedded RTOS) kernel internals     | e-mail: blf at utvinternet.ie
 expert looking for a new position ...       | mobile: (+353 or 0)86 854 9268
  For a résumé, contact me, or see my website  http://www.blf.utvinternet.ie

    Stop E$$o (ExxonMobile):  «Whatever you do, don't buy Esso --- they
     don't give a damn about global warming.»    http://www.stopesso.com
     Supported by Greenpeace, Friends of the Earth, and numerous others...