| 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.
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...
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!