Re: fileutils: inconsistent behaviour stripping / from end of filenames

[Paul Eggert]

> From: Jim Meyering <jim@meyering.net>
> Date: Fri, 14 Sep 2001 13:59:36 +0200
> 
> Paul Eggert <eggert@twinsun.com> wrote:

> > Pathname resolution requires that "dir/" be treated as "dir/." if
> > dir is a symlink to a directory....
> 
> Right.  That was my point.  But I didn't realize it was limited
> to the case in which dir is a symlink to a directory.

Sorry, my statement was too limited.  Actually, in POSIX 1003.1-200x
d7, pathname resolution requires that "dir/" must _always_ be resolved
as "dir/.".  That part is clear enough.  (If "dir" is not a directory,
then "dir/" must fail to resolve, with errno==ENOTDIR.)

The problem arises in other areas, where pathname resolution doesn't
apply.  For example, mkdir("FOO/") does not need to resolve "FOO/" to
a directory, any more than mkdir("FOO") does, because the directory
FOO does not exist yet.  So pathname resolution does not seem to apply
here, and mkdir("FOO/") should perhaps succeed.

Here's another example.  If FOO is a directory, then "FOO", "FOO/",
and "FOO/." all resolve to it, but d7 says that the rmdir function
shall fail "if the path argument refers to a path whose final
component is either dot or dot-dot".  Now, what is the final component
of the path "FOO/"?  If you look at the pathname resolution rule, you
might say that the final component is dot, so rmdir("FOO/") should
fail; but if you look at the definition of pathname component (which
says that a pathname component must be nonempty), you might say that
the final component is "FOO", which means that rmdir("FOO/") should
succeed.

This really does call for an interpretation request, which I'll write.

In the meantime, I think that system utilities should leave the
trailing slashes alone.  E.g. the shell command `rmdir foo/' should
invoke the system call `rmdir("foo/")'; it should not strip the
trailing slash.

Once we know what rmdir("foo/") is supposed to do, perhaps we should
write a replacement that works the "right" way on platforms where it
works the "wrong" way.  That will let fileutils be POSIX-compliant
even on hosts where the underlying system calls are not POSIX-compliant.