[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: Wed, 24 Apr 2013 07:13:13 +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):

                  Status:                   Fixed => None                   


Follow-up Comment #11:

I've applied Paul's updated patch.   However, I think I agree with Eric on the
interpretation of the mode argument.

I propose not to reinstante -perm +MODE with different semantics in the

The fact that this went wrong in the first place underlines the fact that more
regression test cases are needed for -perm.

I don't find the argument from compatibility with chmod very convincing since
the mode argument to chmod is understood to describe a modification to the
mode of an existing file.  In the case of -perm, there is no existing file

Hence a description of how the mode should be interpreted that makes perfect
sense for chmod could still be confusing for find -perm.

This puts me in the uncomfortable position of wondering if mode_change is
really the best basis for find -perm; I'm not sure this is really the intended
use case for that function.   But my first point above probably applies to
gnulib too; if I wanted mode_compile to reject mode strings of the form +MODE
I should probably have contributed a gnulib test case which enforced that.

Anyway I'm marking this bug as not-fixed because better tests are needed (in
findutils, at least).


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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