bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new snapshot available: coreutils-7.6.63-addb6


From: Eric Blake
Subject: Re: new snapshot available: coreutils-7.6.63-addb6
Date: Sun, 04 Oct 2009 08:29:36 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Jim Meyering on 10/4/2009 2:10 AM:
>>  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.
> Such a test would be expected to fail on Linux.
> It's tempting to say "let's make mkdir(1) work around it",

and you even suggested that:
http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00365.html

> 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.

At this point, it's enough of a corner case that I'm okay deferring any
mkdir(1) (or even mkdir(2) cleanups in gnulib) until after coreutils 8.0.
  No point adding a test if we don't even know what behavior we want to
promise.  So all that remains before 8.0 is:

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

Yes, we need to tweak the NEWS to clarify that the new readlink(1)
behavior does not (yet) match mkdir(1) behavior on Linux.

>> $ 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.

I also noticed that 'mkdir -p dangling/' works, only 'mkdir -p
dangling/sub' fails.  So I went ahead and spawned a bug report against
POSIX; we'll see how it fares.  By the way, it is rather difficult to
strip exactly one byte from the end of input using only POSIX commands,
since 'head -c -1' is not standardized:
http://austingroupbugs.net/view.php?id=161
http://www.opengroup.org/austin/mailarchives/ag/msg41004.html
http://www.opengroup.org/austin/mailarchives/ag/msg41002.html
http://www.opengroup.org/austin/mailarchives/ag/msg41003.html

I ended up with the following monstrosity as a shell-based representation
for what I'm proposing as the equivalent for 'mkdir [-m mode] -p "$dir"':

mkdir -p -m $(umask -S),u+wx "$(dirname "$dir" |
  dd bs=1 count=$(($(dirname "$dir"|wc -c) - 1)) 2>/dev/null; echo /)" &&
mkdir [-m mode] "$dir"

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrIsVAACgkQ84KuGfSFAYB/sgCgiBXZaX3pWWFXchhGCwD489bq
IdEAoNlz56dKWFBH28tlrtD46dKGA9Vm
=gL9X
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]