>> That's an argument for using fsdb, not to let root run rampant
>> causing file system corruption.

> If that's the only thing wrong with the file system, I'd rather use
> link and unlink and clri and fsck than dive into fdsb...  [...]

> Fsdb will let you totally screw your filesystem to the point where
> you have to reinstall faster than you can say jack robinson.

So will unlink(2) on directories.  Just apply it to /sbin, say.

Any tool with the power to fix broken filesystems also has the power to
break them worse.

> In any case, I have real strong philosophical problems with removing
> the ability of root to do *anything*... not just link and unlink
> directories.

There are lots of things even root can't do...does it bother you that
root can't write directly to directories?  Can't access kernel VM
directly?  Can't write a raw device whose block device is mounted (rw)
as a filesystem?  Can't bind() a socket to a port which already has a
socket listening to it?  Can't open the master side of a busy pty pair?

> [A]s far as I'm concerned you might as well issue a patch that
> prevents you from creating files and directories with control
> characters or shell metacharacters in them.

I agree with that other person, who said that if such functionality is
left in the kernel at all, it belongs in root-only syscalls linkdir()
and unlinkdir(), not in link() and unlink().  I have a program that
would really like to get EISDIR on an attempt to unlink() a directory,
but has to make a second syscall first (a wasted syscall, most of the
time) to avoid orphaning directories with unlink() if it's run by root.
And I'm not sure it does belong in the kernel.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu