On Wed, 12 Mar 2003, Larry Dwyer wrote:
> This change would preclude a useful extension to UNIX.
>
> There might be an implementation that allowed pathname extensions to
> specify disk volumes or remote volumes. Say, a prefix to pathname
> designates a volume, like, perhaps, "<letter>:". My search path may be, for
> example, "C:/mksnt/mks". My current working directory may be "A:/". I
> should be allowed to do "rm /" and have the expected result.
>
> The same argument applies if I want to have network extensions to the path,
> such as "//<remote_machine_name>".
I am fairly certain that the behavior of "//" was unspecified
("implementation defined?") to allow implementations to do special magic
if they chose. This does not change the meaning of "/" as "*the*
root" to "the root of the directory under the current tree". I am also
fairly certain that DOS-like volume labels were not anticipated/allowed.
DFS traditionally uses "/:/pathname" for DFS volumes where ":" is just a
mount point controlled by the DFS client. "/" still refers to "the" root.
Similarly, autofs implementations often use "/net/". If I have a chance,
and if no one else can remember off the top of their head, I will dig
through the standard and see just what is currently allowed.
So, special casing "rm -rf /" does not prohibit volume designations. The
practice of making volume designations "just another file" fits better
into the UNIX model. That being said, I am not sure I like the idea of the
change; I simply do not think the object is valid.
< ... trimmed ...>
|