[Top][All Lists]

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

[bug #38474] Unintended (?) behaviour change of -perm +mode predicate

From: James Youngman
Subject: [bug #38474] Unintended (?) behaviour change of -perm +mode predicate
Date: Sat, 20 Apr 2013 11:37:32 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.63 Safari/537.31

Update of bug #38474 (project findutils):

             Assigned to:                    None => jay                    


Follow-up Comment #3:

The change was certainly unintended in the sense that when I updated the
gnulib version, I did not expect this behaviour change.   But having re-read
the POSIX standard, I think we have the surprising result that the new
behaviour is correct and the previous behaviour isn't.  But it's possible I'm
mistaken, so please read on (and check the POSIX standard).

I believe POSIX requires that "find . -perm +0100" matches only files which
are mode 0100.   Not files which are executable by their owner but which also
have other bits set.

Here's the description of the -perm predicate from POSIX


-perm [-]mode
The mode argument is used to represent file mode bits. It shall be identical
in format to the symbolic_mode operand described in chmod() , and shall be
interpreted as follows. To start, a template shall be assumed with all file
mode bits cleared. An op symbol of '+' shall set the appropriate mode bits in
the template; '-' shall clear the appropriate bits; '=' shall set the
appropriate mode bits, without regard to the contents of process' file mode
creation mask. The op symbol of '-' cannot be the first character of mode;
this avoids ambiguity with the optional leading hyphen. Since the initial mode
is all bits off, there are not any symbolic modes that need to use '-' as the
first character.
If the hyphen is omitted, the primary shall evaluate as true when the file
permission bits exactly match the value of the resulting template.

Otherwise, if mode is prefixed by a hyphen, the primary shall evaluate as true
if at least all the bits in the resulting template are set in the file
permission bits.


The specified mode argument is "+0100" and it's not preceded by a leading
hyphen.   Hence the mode bit 0100 (64 decimal) is turned on and the match is
exact (since there was no leading "-").   So the predicate matches only files
whose mode is exactly 0100.

I think this means that find-4.5.11 is correct, but previous versions of find
were erroneously selecting the GNU extension behaviour (which is now selected
by -perm /0100) when there is a correct but different POSIX behaviour.

Yes, this is surprising if you didn't know that "+" has been deprecated for a
long time.   See this excerpt from the NEWS file:

* Major changes in release 4.2.21, 2005-06-07
** Functional Changes to find

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.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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