[bugs #11379] find does not descend /proc/<N>/fd without -noleaf

[James Youngman]

This mail is an automated notification from the bugs tracker
 of the project: findutils.

/**************************************************************************/
[bugs #11379] Latest Modifications:

Changes by: 
                James Youngman <address@hidden>
'Date: 
                Wed 12/22/04 at 18:33 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
         Assigned to | None                      | jay
             Summary | does not descend /proc/<N>/fd | find does not descend 
/proc/<N>/fd without -noleaf


------------------ Additional Follow-up Comments ----------------------------
I'm pretty certain that this is a bug in the kernel.  The reason for this is 
that find optimises away stat calls once it knows that it's already seen all 
the subdirectories of the directory it's searching (in this case /proc/1).    
This is because on a Unix filesystem the link count of a directory is 2 more 
than the total number of subdirectories it has (because . and .. make two).  
Hence since on Linux 2.6.x, the /proc/1 directory has a symbolic link count of 
3 (implying one subdirectory) but actually has thee subdirectories (attr, fd 
and task).  Hence find stops checking for subdirectories once it has processed 
the first subdirectory.  

If you specify the -noleaf opiton to disable this optimisation, find will go 
much slower (in general) but will  detect that /proc/1/fd is a directory.







/**************************************************************************/
[bugs #11379] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=11379>
Project: findutils
Submitted by: Egmont Koblinger
On: Wed 12/22/04 at 15:38

Category:  find
Severity:  5 - Average
Item Group:  Wrong result
Resolution:  None
Privacy:  Public
Assigned to:  jay
Originator Name:  
Originator Email:  
Status:  Open
Release:  4.2.7
Fixed Release:  4.2.7


Summary:  find does not descend /proc/<N>/fd without -noleaf

Original Submission:  This bug's happening with findutils 4.1.20 and 4.2.7,
on several different systems running linux kernel 2.6.[7-9].

The command "find /proc/1" executed as root gives this:

/proc/1
/proc/1/task
/proc/1/task/1
/proc/1/task/1/fd
/proc/1/task/1/fd/10
/proc/1/task/1/environ
[...]
/proc/1/task/1/wchan
/proc/1/fd
/proc/1/environ
[...]

as seen, it does not descend to /proc/1/fd, even though it
does have a file inside. The command 'find /proc/1/fd' gives
this output:

/proc/1/fd
/proc/1/fd/10

Similar things happen when executed as a normal user. A
'Permission denied' error message is given for
/proc/1/task/1/fd, but no error is printed for /proc/1/fd,
which has the same permissions (dr-x------).

The bug happens with any process ID, not just PID=1, for
example, try this from a bash:
find /proc/$$ ; echo ; find /proc/$$/fd

On Linux 2.4 kernels, which lack /proc/<NUM>/task, find
behaves correctly.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 12/22/04 at 18:33         By: James Youngman <jay>
I'm pretty certain that this is a bug in the kernel.  The reason for this is 
that find optimises away stat calls once it knows that it's already seen all 
the subdirectories of the directory it's searching (in this case /proc/1).    
This is because on a Unix filesystem the link count of a directory is 2 more 
than the total number of subdirectories it has (because . and .. make two).  
Hence since on Linux 2.6.x, the /proc/1 directory has a symbolic link count of 
3 (implying one subdirectory) but actually has thee subdirectories (attr, fd 
and task).  Hence find stops checking for subdirectories once it has processed 
the first subdirectory.  

If you specify the -noleaf opiton to disable this optimisation, find will go 
much slower (in general) but will  detect that /proc/1/fd is a directory.













For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=11379>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/