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

[Egmont Koblinger]

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

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

Changes by: 
                Egmont Koblinger <address@hidden>
'Date: 
                Wed 12/22/04 at 22:09 (GMT)

------------------ Additional Follow-up Comments ----------------------------
Hi Jay!

You're right, this is a kernel bug then, I'll soon report it
to the kernel folks.

On the other hand:

On recent systems, the "struct dirent" returned by readdir()
contains a d_type field which might (but not necessarily
does) provide information about the file type. E.g. it can
be DT_UNKNOWN meaning that stat() has to be performed in the
old-fashioned way to get the file type, but in the mean
time, it can also be DT_REG, DT_DIR and so on (see
/usr/include/dirent.h).

Whether or not this is supported depends on the operating
system as well as the filesystem type, for example, on reiserfs always 
DT_UNKNOWN is returned, but ext3 returns
normal values. And, fortunately, procfs also supports this
feature.

It would be very nice then if findutils, whenever available
(I know, both compile-time and run-time detection is needed,
run-time detection on a per-file basis), took advantage of
this feature (and ignored the -leaf/-noleaf option for those
directories). This would have at least two advantages:

- would be even faster than the current way since much more
stat() calls can be avoided,

- would be a perfect workaround for the kernel's /proc/PID
hardlink count problem.







/**************************************************************************/
[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 22:09         By: Egmont Koblinger <egmont>
Hi Jay!

You're right, this is a kernel bug then, I'll soon report it
to the kernel folks.

On the other hand:

On recent systems, the "struct dirent" returned by readdir()
contains a d_type field which might (but not necessarily
does) provide information about the file type. E.g. it can
be DT_UNKNOWN meaning that stat() has to be performed in the
old-fashioned way to get the file type, but in the mean
time, it can also be DT_REG, DT_DIR and so on (see
/usr/include/dirent.h).

Whether or not this is supported depends on the operating
system as well as the filesystem type, for example, on reiserfs always 
DT_UNKNOWN is returned, but ext3 returns
normal values. And, fortunately, procfs also supports this
feature.

It would be very nice then if findutils, whenever available
(I know, both compile-time and run-time detection is needed,
run-time detection on a per-file basis), took advantage of
this feature (and ignored the -leaf/-noleaf option for those
directories). This would have at least two advantages:

- would be even faster than the current way since much more
stat() calls can be avoided,

- would be a perfect workaround for the kernel's /proc/PID
hardlink count problem.


-------------------------------------------------------
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/