/dev/fd/3 issue

[otsuarez]

Hi all:
I am having this weird problem which just don't know how to solve. I have a iBook G3 500MHz with OS X 10.2.8 on a 10GB HDD. Having little space remaining I decided to investigate what was happening. After doing a
du -ks /* I found this:

rental@osx:~$ sudo du -ksc /*
Password:
1228260 /Applications 1.2GB
99088 /Developer
378560 /Library
912240 /System
3397676 /Users 3.4GB
3396132 /dev 3.3GB
40152 /opt
409904 /private 0.4GB
1972 /sbin
1612772 /sw 1.6GB
0 /tftpserver
4 /tmp
1018760 /usr 1GB
4 /var
12504530 total
(the GB numbers are mine)
Everything was ok except for the /dev/ directory so I did this:
rental@osx:~$ sudo du -ks /dev/*
Password:
0 /dev/bpf0
0 /dev/bpf1
....
0 /dev/disk0s9
3406972 /dev/fd
0 /dev/klog
...
0 /dev/vn3
0 /dev/zero
rental@osx:~$
I didn't expect the /dev/fd result, so I took the next step
rental@osx:~$ sudo du -ks /dev/fd/*
Password:
0 /dev/fd/0
0 /dev/fd/1
0 /dev/fd/2
du: /dev/fd/255: Bad file descriptor
du: /dev/fd/3: Bad file descriptor
rental@osx:~$

What Bad file descriptor means?

rental@osx:~$ sudo ls -l /dev/fd
Password:
total 0
crw-rw-rw- 1 root wheel 4, 1 Apr 29 15:26 0
crw-rw-rw- 1 root wheel 4, 1 Apr 29 15:26 1
crw-rw-rw- 1 root wheel 4, 1 Apr 29 15:26 2
drw-r--r-- 119 rental staff 4046 Apr 28 19:45 3
dr--r--r-- 2 root wheel 512 Apr 29 10:58 4
rental@osx:~$

I found strange that /dev/fd/3 is own by my user. It's that ok?
I even reboot in single user but then, after mount -uw /, /dev/fd didn't exist.
Having only 850MB available I am really curious in knowing what it is happing (and why I am loosing 3GB on some /dev/fd file).
Regards,
Osvaldo

[huskerchad]

The "/dev/fd*" files are special devices. These aren't really taking up that much space on your system. They allow a process to access file descriptors by number; 0,1,2 are standard input, standard output, and standard error, and other open files start with 3.

[otsuarez]

Yes, I agree with you, but then, does that mean that those 3 GB reported by /dev/fd are not really physically used on my hdd?

[hayne]

I don't know if this is still true, but I think I recall that the /dev/ stuff gets recreated at each boot (could that be correct?)
If so, it would be interesting to see what happens to your disk space when you reboot. But of course don't get confused by the fact that you will recover the space used by the swap files in /var/vm when you reboot.

[huskerchad]

It depends on what it was pointing to at the time the time 'du' came across it. If it was some kind of a pipe, du might have read a lot of bits that don't really exist on your hard drive. Or it might have been pointing to some real file that was 3GB in size. In any case, the /dev/fd files are not the source of the problem.

[otsuarez]

i did reboot (a couple of times in fact) and the issue remains. When I reboot in single user mode, the /dev/df didn't show up.
(and of course, each reboot do some cleaning, but alway around the hundred MBs)

[otsuarez]

Is there any way of knowing where does the /dev/fd/3 file descriptor is pointing to? (I check man lsof and didn't found out anything useful). Any hint? (ok, now I agree that /dev/fd is just a file descriptor)

[yellow]

I've been seeing this on both my home machne and my work machine.

du: `/dev/fd/3': Bad file descriptor
du: `/dev/fd/5': Bad file descriptor

[breen]

Hmm... just a guess here.

I just tried the same thing and got a huge amount of output from 'du /dev/fd'

I think we're seeing transitory file handles -- whatever the du program had opened using file handle 3 is closed by the time it tries to read it -- and so the file descriptor for that handle is already gone.

This looks like normal behavior to me - nothing to worry about.

Breen