Quote:>Looking in /dev/fd, I see files corresponding to file descriptors
>0 through 62, notwithstanding that only 0, 1, and 5 are actually
>open. But that behavior is not described in the fd(4) man page.
Not explicitly, but so what?
If you do a readdir() on /dev/fd then you see entries for all numbers
less that the current soft fd limit, e.g.
$ (ulimit -n 12 ; ls -f /dev/fd)
. .. 0 1 2 3 4 5 6 7 8 9 10 11
This doesn't necessarily cover all currently open fd's. But you can
stat() any number inside /dev/fd and it will get you an answer:
$ ulimit -n
$ ls -l /dev/fd/99999
crw-rw-rw- 1 root root 234,99999 May 26 17:03 /dev/fd/99999
An entirely nominal answer, because there is no device driver for this
character device. If you did a "mknod /some/device c 234 99999" then
/some/device would not behave like /dev/fd/99999.
The effect of opening an entry in /dev/fd (i.e. dup()ing the referenced
fd) is unrelated to the results of readdir() or stat(). Filing system
implementations can do things like that!
Quote:>So is there any reason to have both /dev/fd and /proc/self/fd ?
I think opening a file in /proc/self/fd is slightly different from the
dup()ing that /dev/fd does. You get an independent seek pointer, for
Quote:>Or to put it another way, is there anything that would break if
>one removed the /dev/fd line from /etc/vfstab and replaced the
>/dev/fd line with a symlink to /proc/self/fd ?
Ugh! Anyone want to try the experiment?
Quote:>If not, why maintain both?
/dev/fd is much older, of course (in Solaris it goes back to 2.0 vs 2.6),
and it exists in more Unix flavours.
Email: cet1 [at] cam.ac.uk