On Wed, 12 Mar 2003 yyyyyyyyyyyyyyy@xxxxxx wrote:
> The single root viewpoint is central to UNIX.
>
> You may or may not know that under Linux every
> process may see its own file hierarchy.
> Linux has many root directories, in principle,
> somewhat like Plan9.
>
> [and I am not referring to chroot or so]
I do know that actually, but, since chroot already provides something
close, it does not affect the discussion as far as I can see. Such
capabilities are very important in applications like distributed computing
where a host is providing computation services. You also have cases like
the new light-weight plex86 implementation where you have a Linux kernel
running in userland to provide virtualization.
Even there, "/.." is still equivalent to "/". The root directory is still
*the* root directory for the process. It is not like DOS where giving a
directory designator ("E:\") causes you to suddenly have a different root
directory. Nor, as far as I am aware, can you successfully delete or
unlink "/" itself. In fact, in these applications it is critical that the
process cannot see outside of its designated file system (and the
resources that it has the ability to mount). The process is provided with
a root. It can attach what it needs to that root. The root, to the extent
that it has any physical existance, is cleaned up by the parent.
I think it makes some sense to consider "/" on the same terms as "." and
"..". It is a directory that only has a logical existance and cannot be
removed, renamed, etc.
rm, step 4 requires that "rm shall perform actions equivalent to the
rmdir() function. It is already specified that rmdir() "shall fail if:
[EACCES]
Search permission is denied on a component of the path prefix, or write
permission is denied on the parent directory of the directory to be
removed.
[EBUSY]
The directory to be removed is currently in use by the system or some
process and the implementation considers this to be an error.
..."
It can be readily argued that the process does not have permission to
write to the parent directory of "/" since "/" *has no parent*. In cases
where the process has its own root provided by the parent process, the
process still cannot write to "/"'s parent.
Disregarding that, many implementations document that they fail with
[EBUSY] if rmdir is called with an active mount point, which "/" certainly
is. I am, however, singularly unwilling to verify the actual behavior
(whether EACCES OR EBUSY is returned) on the systems I have access to at
the moment (-:. So, it can be argued that rmdir() is required to fail for
slash. It is certainly allowed to fail for slash. It is not much of a
stretch to either allow or require (depending on interpretation of rmdir()
requirements) an implementation to make a user remove the contents of
slash via "rm -rf /*" instead of "rm -rf /". I certainly doubt that there
is a large body of code (scripts or otherwise) that currently depends on
the ability to delete "/" and the amount of code that may mistakenly
attempt to delete "/" is likely much higher in any case.
So, anyway, I can see the original poster's point of view.
|