Clamxav scan came up with dev/fd/3 can't open file

Question

Hi all!
I'm running a clamxav scan as i am worried that i may have something on my comp after a security compromise on one of my gaming accounts. It has come up with
"WARNING: Can't open file /dev/fd/3: Permission denied"
and as i have no idea about computers or what on earth this file is or used for i am not sure if it is anything i need to worry about...
Thanks for your help!

Answer 1

Welcome to Apple Support Communities
It's nothing to worry about, it's actually a little bit of developer code to find the file descriptor of an application, not something a user needs to read or write so just forget about it.
More: +To understand what is going on, first note that "/dev/fd" is a "virtual" thing. It is a kind of a hack (developed for the use of shell scripts, I think) that gives a program a view of *its own* file descriptors.+
+This means that if I have two programs running (e.g., '/bin/bash' and '/usr/bin/du'), and each of those looks in "/dev/fd", they could see different things. Each will see one file for each file descriptor that it has open, and the name of the file will be the number of that open descriptor.+
+For example, by default, each program will have three open file descriptors, 0, 1, 2 (stdin, stdout, stderr). Different programs will have different ones open, so what you saw above is the result of that. The shell looked in "/dev/fd" and saw a number of files, one for each of its open files. The names were then passed to 'du' on the command line, as if the command were+
+du -ks /dev/fd/0 /dev/fd/1 /dev/fd/2 /dev/fd/3 ...+
+Then 'du' runs. Without looking at the code, I can only guess, but what has to be happening is that 'du' has closed FD 3, and when it tries to get information about '/dev/fd/3', the kernel gives it an error. The error is "EBADF" (see '/usr/include/sys/errno.h'), because access to "/dev/fd/3" is the same as accessing file descriptor 3 (for example, stat("/dev/fd/3",...) is the same as fstat(3,...))."+
http://lists.apple.com/archives/Darwinos-users/2004/Apr/msg00042.html