> (talking about my bug report which deletes the ability of root to link &
> unlink directories):
> 
> Peter> This is not a bug.  It is a feature.
> 
> Peter> It is not for us to decide that the superuser is wrong.
> 
> Peter> It is periodically very handy for debugging or breaking
> Peter> filesystems, or fixing broken ones.  (In particular, it's one
> Peter> possible way to fix a filename with a '/' in it.)
> 
> That's an argument for using fsdb, not to let root run rampant causing
> file system corruption.  Using fsdb makes it absolutely clear that
> you're intentionally doing something dangerous.  Using unlink(2) on
> directories is just the _Wrong Way_ to fix a damaged/broken filesystem!

The linking and unlinking of directories is legacy code from when the
way to move a directory was to link it then unlink it as seperate
non-atomic operations.  The rename() call fixed this.

Because the rename() call can be crashed in the middle of its operation
by a power failure, I think the unlink is still important.

Personnally, I removed the ability to link directories in several Novell
and USL UFS derived file systems, and strongly urged the removal of the
capability in UFS itself (I have confidence in the person over the work
on UFS at this time and believe that it will die eventually).

The ability to hard-link directories screws horribly with the ability
to track directory heirarchy for ACL's, and is thus a potential for
some huge security holes on more modern file systems.

POSIX neither requires nor disallows the capability (much like the
ability to truncate files, it is ignored).


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.