bugfindutils - Bugs: bug #11379, find does not descend...

 
 

bug #11379: find does not descend /proc/<N>/fd without -noleaf

Submitter:  Egmont Koblinger <egmont>
Submitted:  Wed 22 Dec 2004 03:38:16 PM UTC
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Invalid
Privacy:  Public Assigned to:  jay
Originator Name:  Open/Closed:  Closed
Release:  4.2.7 Fixed Release:  4.2.7
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Wed 22 Dec 2004 10:09:16 PM UTC, comment #2: 

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.

Egmont Koblinger <egmont>
Wed 22 Dec 2004 06:33:22 PM UTC, comment #1: 

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.

James Youngman <jay>
Project Administrator
Wed 22 Dec 2004 03:38:16 PM UTC, 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.

Egmont Koblinger <egmont>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

 

 

 

Follow 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-21 marvin Carbon-Copy- Added marvin
2005-01-03 jay Open/ClosedOpen Closed
2005-01-01 jay StatusNone Invalid
2004-12-22 jay Assigned toNone jay
    Summarydoes not descend /proc/<N>/fd find does not descend /proc//fd without -noleaf

Back to the top


Powered by Savane 3.9