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

 
 

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

Submitted by:  Egmont Koblinger <egmont>
Submitted on:  Wed 22 Dec 2004 03:38:16 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Invalid
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Open/Closed: Closed
Release: 4.2.7Fixed Release: 4.2.7

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

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 AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

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 5 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Thu 21 Jul 2005 08:41:56 AM UTCmarvinCarbon-Copy-=>Added marvin
Mon 03 Jan 2005 10:15:30 PM UTCjayOpen/ClosedOpen=>Closed
Sat 01 Jan 2005 08:17:39 PM UTCjayStatusNone=>Invalid
Wed 22 Dec 2004 06:33:22 PM UTCjayAssigned toNone=>jay
  Summarydoes not descend /proc/<N>/fd=>find does not descend /proc//fd without -noleaf

Back to the top


Powered by Savane 3.1-cleanup1