Following find commandline gives me "Permission denieds" for directories which don't even match the expressions: find /tmp -maxdepth 1 -mtime -1 -type f -name 'Acro*' -user "$LOGNAME" -print0 LOGNAME is the user of the invoking command. find still seems to touch all the files in /tmp even the expressions don't match. Any ideas?
post some actual output and the permissions of the files/dirs
find /tmp -maxdepth 1 -mtime -1 -type f -name 'Acro*' -user "$LOGNAME" -print0 output: find: /tmp/kde-root: Permission denied find: /tmp/.gnome: Permission denied find: /tmp/.gnome_private: Permission denied expected output: <nothing> This was working in an older release, well i don't have one now, but i know it worked with find-4.1.7.
Ok, now more in detail: with findutils-4.1.20-r2 or oldfind i get: $ oldfind /tmp -maxdepth 1 -mtime -1 -type f -name 'Acro*' -user "$LOGNAME" -print0 <nothing> $ find /tmp -maxdepth 1 -mtime -1 -type f -name 'Acro*' -user "$LOGNAME" -print0 find: /tmp/kde-root: Permission denied find: /tmp/.gnome: Permission denied find: /tmp/.gnome_private: Permission denied So the expected behaviour changed. Any idea?
the behavior you're seeing is correct you asked find to descend at most 1 directories and look for a file whose name begins with Acro and is owned by user $LOGNAME since find could not descend into those directories, it issued an error
Why should this behaviour be correct. The error message does not say that no directory /tmp/Acro* exists and /tmp/Acro* does in no way resolve to /tmp/kde-root. Why should it give me a permission denied for a directory which should not even be invoked by the give expression? oldfind handles this correctly.
Could it be that the meaning of -maxdepth has changed? Where -maxdepth x was correct before, now maxdepth x-1 is now correct? With strace i can see that with oldfind ... -maxdepth 0 nothing is 'stat'ed by oldfind, with find ... -maxdepth 0 it stats all files directly in /tmp what equals to oldfind ... -maxdepth 1.
seems to be working for me with 4.3.2 / 4.2.29
(In reply to comment #7) > seems to be working for me with 4.3.2 / 4.2.29 > Yes, i reported it upstream, so that the bug gets fixed.
