Re: new snapshot available: coreutils-7.6.63-addb6

[Jim Meyering]

Eric Blake wrote:
> According to Jim Meyering on 10/3/2009 2:30 AM:
>> There have been *many* changes in gnulib since the previous snapshot,
>> and the changes in coreutils are non-negligible, so please give
>> this a try.  I'd like to make the beta release on Monday.
>> I'll probably call it coreutils-8.0.
>
> I'm still wondering if we want one more patch: now that we document that
>
>  readlink -f link/
>
> succeeds, with the claim that 'mkdir link/' will also succeed, we should
> make sure of that.

Yes, adding a test would be good.

> Right now, Solaris systems work (mkdir(2) follows
> POSIX), but GNU/Linux reject it (since mkdir(2) fails with EEXIST on a
> slashed symlink).

Such a test would be expected to fail on Linux.
It's tempting to say "let's make mkdir(1) work around it",
but I would like to avoid adding any more uses of
canonicalize_* functions, due to their inherent problems.

If you feel like addressing that right away, that would
be great.  Otherwise, I think it's safe to say that no one
will complain if it is deferred until 8.1.

Or, we could simply document the situation, changing the readlink(1)
claim to defer to "POSIX-conforming mkdir(2)" semantics.

> What's worse, I wonder if we have a bug on Solaris:
>
> $ rm -Rf ?
> $ ln -s a b
> $ mkdir -p b/c
> mkdir: cannot create directory `b': File exists
> $ mkdir b/
> $ mkdir b/c
>
> or if it is a bug in POSIX, since it describes mkdir -p in terms of
> "$(dirname dir)" rather than "$(dirname dir)/".  The native Solaris
> /bin/mkdir also fails with mkdir -p b/c, but with ENOENT.

Interesting.
That shows how dark and dusty this particular corner of the standard is.