[bug-notifications] [findutils 0001014]: new 4.2.23 stable release announced

Mantis Bug Tracker noreply at opencsw.org
Sun Jul 3 05:34:36 CEST 2011

The following issue has been CLOSED 
Reported By:                pfelecan
Assigned To:                car
Project:                    findutils
Issue ID:                   1014
Category:                   upgrade
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     closed
Resolution:                 fixed
Fixed in Version:           
Date Submitted:             2005-06-20 16:36 CEST
Last Modified:              2011-07-03 05:34 CEST
Summary:                    new 4.2.23 stable release announced
* Major changes in release 4.2.23

** Documentation Changes

The -L and -I options of xargs are currently incompatible (but should
not be).

Improved the documentation for -execdir and -okdir.

** Functional Changes to updatedb

File names ending in \"/\" which are specified as an argument
--prunepaths (or in $PRUNEPATHS) don\'t work, so we now issue an error
message if the user tries to do that.  The obvious exception of course
is \"/\" which does work and is not rejected.

* Major changes in release 4.2.22

** Security Fixes

If a directory entry searched with \"find -L\" is a symbolic
link to
\".\", we no longer loop indefinitely.  This problem affected
versions 4.2.19, 4.2.20 and 4.2.21.  This problem allows users to make
\"find\" loop indefinitely.  This is in effect a denial of
service and
could be used to prevent updates to the locate database or to defeat
file security checks based on find.  However, it should be noted that
in any case you should not use \"find -L\" in

** Other Bug Fixes

None in this release.

** Functional Changes to locate

A locate database can now be supplied on stdin, using \'-\' as a element
of the database-path. If more than one database-path element is \'-\',
later instances are ignored.

A new option to locate, \'--all\' (\'-A\') causes matches to be limited
entries which match all given patterns, not entries which match
one or more patterns.

** Documentation Changes

Some typos in the manual pages have been fixed.  Various parts of the
manual now point out that it is good practice to quote the argument of
\"-name\".  The manpage now has a \"NON-BUGS\" section
which explains some
symptoms that look like bugs but aren\'t.  The explanations of the
and \"%b\" directives to \"find -printf\" have been

* Major changes in release 4.2.21
** 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
Use the new syntax \"find ... -perm /MODE\" instead.  Old usages
still continue to work, so long as they don\'t conflict with POSIX.

If the output is going to a terminal, the -print, -fprint, -printf and
-fprintf actions now quote \"unusual\" characters to prevent
effects on the terminal.  See \"Unusual Characters in File
Names\" for
further details.  There is no change to the behaviour when the output
is not going to a terminal.   The locate program does the same thing,
unless the -0 option is in effect (in which case the filenames are 
printed as-is).

** Functional Changes to locate

The locate command will now read each locate database at most once.
This means that if you are using multiple databases and are searching
for more than one name, the results will now be printed in a different
order (and if you specified a small limit with --limit, you may get a
different set of results).

A new option \'--print\' for locate causes it to print the matching
results even if the \'--count\' or \'--statistics\' option is in effect.

** Bug Fixes
find /blah/blah/blah -depth -empty now works once again.

The -regex and -iregex tests of find now correctly accept POSIX Basic
Regular Expressions.  (Savannah bug

The updatedb program now works on systems where \"su\" does not
the \"-s\" option, for example Solaris.


 (0006397) car (reporter) - 2009-07-04 01:25
Done: 4.4.2 published.  In truth, this bug could probably have been closed
some time ago.

More information about the bug-notifications mailing list