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