From: Brian Foster (blf at domain utvinternet.ie)
Date: Tue 25 Jun 2002 - 23:07:12 IST
| Date: Mon, 24 Jun 2002 17:33:05 +0100
| From: Padraig Brady <padraig at domain 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 domain 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...
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:17:32 GMT