# find /proc -group root -print > /dev/null &
[1] 10966
# find: /proc/tty/driver: Permission denied
find: /proc/1/task/1/fd: Permission denied
find: /proc/2/task/2/fd: Permission denied
.
.
.
find: /proc/8456/task/8456/fd: Permission denied
find: /proc/10634/task/10634/fd: Permission denied
find: /proc/10966/task/10966/fd/4: No such file or directory
[1]+ Exit 1 find /proc -group root -print >/dev/null
Note that the last error message from 'find', with the error you mention
(no such...) is for .../task/10966/... which is the PID of the
backgrounded 'find'. Also, FYI, all the 'permission denied' messages
are for currently running processes that I don't own.
The error msg line gets a new "N" in the path because there's a new PID
generated each time you run the command.
The '.../fd/' directory contains the file descriptor numbers for any
open files, so 'find' is opening a couple of files (the directory from
which it will begin searching is one, don't know what the other might
be). This creates a couple of new 'fd' values (3, 4), since stdin,
stdout and stderr (0, 1, 2) are already open. 'find' then presumably
(this is a guess, I'm not familiar with the code) reads the full
directory listing (recursively), closes the discriptor (4), then does a
'stat' on each file, for additional information. But, since the fd has
been closed, it no longer exists and can't be stat'd, causing the error.
Bob
Vladimir Zolotykh wrote:
Just out of curiosity, why
sudo find /proc -group backup -print
always terminates with
find: /proc/N/fd/4: No such file or directory
where N is always a new number ?
[Sarge, GNU/Linux]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
