Messages in this thread | | | Date | Thu, 21 Mar 1996 08:35:10 +0200 (EET) | From | Linus Torvalds <> | Subject | Re: rmdir system call |
| |
On Wed, 20 Mar 1996, Aaron Crane wrote: > > Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote: > > > > Should you be able to call rmdir with a trailing '/'? > > > > Traditionally its invalid, but I think POSIX allows it to support > > more stupid programs; therefore "//bin", "/usr//bin", and "/etc/" > > should all be valid directory names; maybe even combinations of > > these.
I don't think POSIX allows it at all. What POSIX says (this is from memory) is roughly that a empty filename component is to be interpreted as a ".", with the exception of empty components at the start of a path which are system-dependent.
What that means is that
//ftp/tsx-11.mit.edu/pub/xx
is not necessarily the same as
/ftp/tsx-11.mit.edu/pub/xx
but two slashes anywhere else are ok (/tmp////x == /tmp/x)
This is traditional UNIX behaviour, and the reason for the special case for the start of the path was that some UNIX implementations have used a initial "//" to mean that we move to another name space (for example, for network names).
Personally, I think that the initial // behaviour is totally broken, because it's against the whole unix philosophy of having a unified file system name space, but we don't really need to care about it, and linux handles that the "correct" way (as do just about all the other "normal" unixes out there).
Anyway, to finally get to the point, POSIX doesn't specify much about trailing slashes, and leaves that question open. Linux considers such a pathname (eg "/tmp/") to have an implicit "." at the end, so when you do a "mkdir("/tmp/")" linux thinks you try to create a zero-length filename in the "tmp" directory, and a zero-length filename is the same as ".", so it doesn't work.
The linux interpretation is legal as far as I know (I think there are other unixes that do it the same way), and it also has the added bonus of being the logical thing to do. Because a rmdir("/tmp/") system call really _does_ ask the kernel to remove the zero-length filename "" from the /tmp directory. It does _not_ ask to remove the tmp directory itself.
> Yeah, point taken, but if we put that code into the kernel, then it only > has to exist in one place. If we require it to be done by user code then > every user program has to check (for example) paths supplied by the user > for extra occurrences of /. Anyway, if Posix says so, it *must* be a good > idea ;). Alternatively, perhaps /- stripping could go into libc instead. > Opinions, anyone?
I'll never do slash stripping in the kernel, and that's pretty final (but see later about standards). The library is another matter, but whether it's a good diea is debatable. I personally don't think it's a good idea, at least until some standard _requires_ us to do it (and then I might as well do it in the kernel, but I don't have to like it).
Linus
| |