bugfindutils - Bugs: bug #17951, find doesn't correctly stat...

 
 

bug #17951: find doesn't correctly stat directories

Submitted by:  None
Submitted on:  Mon 09 Oct 2006 12:02:25 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Duplicate
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Ronny PeineOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 4.3.0
Fixed Release: 4.3.2

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Sat 03 Mar 2007 02:06:39 AM UTC, comment #6:

The patch attached to bug #17372 fixes this problem, and is included in findutils-4.3.2, so this bug is fixed in an existing release. Thanks for letting me know.

James Youngman <jay>
Project AdministratorIn charge of this item.
Wed 08 Nov 2006 07:32:50 PM UTC, comment #5:

Yes it fixes my problem, too. So i think it is correct that this bug has the same source. Big thanks for your help.

Anonymous
Wed 08 Nov 2006 07:18:30 AM UTC, comment #4:

Could you tell me if the patch attached to bug #17372 fixes your problem also?

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 06 Nov 2006 09:33:40 AM UTC, comment #3:

Well, i think after reading the bugreport #17372 that it seems to be related, maybe possibly the same error. So you can mark it as a duplicate if you want.

Anonymous
Sun 05 Nov 2006 01:56:24 AM UTC, comment #2:

Is this essentially the same problem as bug #17372 ? That's fixed in CVS.

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 09 Oct 2006 02:00:39 PM UTC, comment #1:

Ok, i have found out what the problem is in detail:
find ... -maxdepth 0 not only uses lstat64 on the given directory /tmp but also on all files in /tmp in the first hierarchylevel. oldfind ... -maxdepth 0 only uses lstat64 on /tmp. oldfind shows the same behaviour as find if -maxdepth is set to 1. So oldfind -maxdepth x corresponds to find -maxdepth x-1.
In the manpage for find it says:
-maxdepth levels
Descend at most levels (a non-negative integer) levels of directories below the command line arguments. `-maxdepth 0' means only apply the tests and actions to the command line arguments.

My question now is: Does apply tests and actions to the given command line include opening the directory and lstat64 all files in this directory?

This changed behaviour led to my first posted problem because find -maxdepth 1 ... wants to open each directory in /tmp to see for a file equal to 'Acro' but it should only see in /tmp if 'Acro' exists, therefor the given "Permission denied"-messages.

Anonymous
Mon 09 Oct 2006 12:02:25 PM UTC, original submission:

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-4.3.0 still seems to touch all the files in /tmp even the expression Acro* doesn't match.

Given Output:
find: /tmp/kde-root: Permission denied
find: /tmp/.gnome: Permission denied
find: /tmp/.gnome_private: Permission denied

Expected Output:
<nothing>

Previous find versions were working correctly in this case.
The 'oldfind' binary works correctly, too.
For me this seems related to the new 'fts'.

Any advice or idea?

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jay (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 03 Mar 2007 02:06:39 AM UTCjayOpen/ClosedOpen=>Closed
      Fixed ReleaseNone=>4.3.2
    Thu 09 Nov 2006 03:32:40 AM UTCjayStatusNeed Info=>Duplicate
      Assigned toNone=>jay
    Wed 08 Nov 2006 07:18:30 AM UTCjayStatusNone=>Need Info
    Mon 09 Oct 2006 12:02:25 PM UTCNoneCarbon-Copy-=>Added -nicht verfügbar-

    Back to the top


    Powered by Savane 3.1-cleanup1