This is the mail archive of the
cygwin-talk
mailing list for the cygwin project.
Re: [ANNOUNCEMENT] Updated [experimental]: findutils-4.3.0-1
- From: ericblake at comcast dot net (Eric Blake)
- To: Read the manual!,<cygwin-talk at cygwin dot com>
- Date: Wed, 18 Jan 2006 15:06:09 +0000
- Subject: Re: [ANNOUNCEMENT] Updated [experimental]: findutils-4.3.0-1
- Reply-to: The Cygwin-Talk Malingering List <cygwin-talk at cygwin dot com>
>
> Ok, thanks! BTW, is /0444 also new? Didn't it use to be +0444?
Yes. Actually, -perm +0444 still does the same as -perm /444,
(as it is an extension to POSIX), but -perm +a+r does not
behave like -perm /a+r (POSIX requires -perm +a+r to behave
the same as -perm 444, not -perm /444).
Or you could reread the manual:
$ grep -iC3 '/mode' /usr/share/doc/findutils*/NEWS
I'd like to point out a second time that the interpretation of '-perm
+mode' has changed to be more POSIX-compliant. If you want the old
behaviour of the GNU extension you should use '-perm /mode'. See the
NEWS entry for findutils version 4.2.21 for details.
** Functional Changes
--
The GNU extension "find ... -perm +MODE" has been withdrawn because it
is incompatible with POSIX in obscure cases like "find ... -perm ++r".
Use the new syntax "find ... -perm /MODE" instead. Old usages will
still continue to work, so long as they don't conflict with POSIX.
Or even my release notes:
http://sourceware.org/ml/cygwin-announce/2005-09/msg00002.html
http://sourceware.org/ml/cygwin-announce/2005-12/msg00018.html
And if you can't sleep at night, the long, lengthy explanation of the
finer semantic points are in this bug report:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=14619
>
> Interesting... FWIW, I think having one -access test (and reusing the
> code from -perm to parse +r/+w/+x/=r/=w/=x/-r/-w/-x) makes more sense...
Why don't you propose it upstream? The problem is the code for
parsing symbolic permissions in -perm also parses stuff like
sticky bits, and access() doesn't grant you visibility into that; also,
it doesn't make sense to do -access g+r (when using access(), a
file is either readable or it is not, without any bearing on user,
group, or other, but accounting for ACLs; when using stat(), there
really are 9 access bits to compare against, plus 3 extra bits, but
with no ACL knowledge). So I think James' choice of -readable,
-writable, and -executable were probably the right way to do it.
Shoot - did I just give a valid technical reply on the -talk list? I just
hope no hippos fall on me tonight!