Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!cuae2!ltuxa!we53!sw013b!dj3b1!killer!jfh
From: jfh@killer.UUCP
Newsgroups: comp.bugs.sys5
Subject: Re: Unlinking "."
Message-ID: <736@killer.UUCP>
Date: Fri, 3-Apr-87 15:21:15 EST
Article-I.D.: killer.736
Posted: Fri Apr  3 15:21:15 1987
Date-Received: Sun, 5-Apr-87 12:43:58 EST
References: <1059@cci632.UUCP> <5715@brl-smoke.ARPA>
Organization: The Unix(tm) Connection, Dallas, Texas
Lines: 32
Keywords: unlink
Summary: What about renaming directories?

In article <5715@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <1059@cci632.UUCP> rrw@cci632.UUCP (Rick Wessman) writes:
> >In our version of Unix*, PERPOS**, it is legal to remove ".", and there
> >is a raging controversy about whether it should be.
> 
> Since directories in the Unix file system are required to have "."
> and ".." entries, it does not make sense to permit their removal.
> 
> The best solution would seem to be to use system calls to create
> and remove directories, instead of super-user privileged processes
> that invoke link(2) and unlink(2).  This also lets you avoid race
> conditions that the latter approach is heir to.
> 
> Current BSD and System V releases have mkdir(2) and rmdir(2) calls.

In the absense of rmdir(2) and rename(2) calls, you must be able to unlink
directory entries "." and "..".

If your rmdir(1) program doesn't bother to unlink ".", then the directory will
not go away and fsck(1) will decide that it is orphaned and place it in
/lost+found.

The next problem has to do with renaming directories.  If you do not permit
".." to be removed, then cd .. from the renamed directory won't work.

Doug is right about the races, but if you start moving all of the utilities
into the kernel, Sys5 will wind up looking a little fat.  There are plenty
of good reasons to let people unlink "." and "..".  Fix the races instead.

- john.		(jfh@killer.UUCP)

No disclaimer.  Whatcha gonna do, sue me?