Question

I　traced an oracle process, and find it first open a file /etc/netconfig as file handle 11, and then duplicate it as 256 by calling fcntl with parameter F_DUPFD, and then close the original file handle 11. Later it read using file handle 256. So what’s the point to duplicate the file handle? Why not just work on the original file handle?

12931:   0.0006 open("/etc/netconfig", O_RDONLY|O_LARGEFILE)    = 11
12931:   0.0002 fcntl(11, F_DUPFD, 0x00000100)                  = 256
12931:   0.0001 close(11)                                       = 0
12931:   0.0002 read(256, " # p r a g m a   i d e n".., 1024)   = 1024
12931:   0.0003 read(256, " t s           t p i _ c".., 1024)   = 215
12931:   0.0002 read(256, 0x106957054, 1024)                    = 0
12931:   0.0001 lseek(256, 0, SEEK_SET)                         = 0
12931:   0.0002 read(256, " # p r a g m a   i d e n".., 1024)   = 1024
12931:   0.0003 read(256, " t s           t p i _ c".., 1024)   = 215
12931:   0.0003 read(256, 0x106957054, 1024)                    = 0
12931:   0.0001 close(256)                                      = 0

Answer 1

As an aside, they’re file descriptors rather than file handles. The latter are a C feature used with fopen and its brethren while descriptors are more UNIXy, for use with open et al.

Interesting. The only reason that comes to mind is that some other piece of code has a specific need for the file descriptor to be 256. I suspect only Oracle would know the bizarre reasons for that. In any case, you’re not guaranteed to get 256, you get the file first available file descriptor greater than or equal to that number.

---

From a bit of investigation (I don’t know every little thing about the innards of UNIX off the top of my head), there are attributes that belong to a group of duplicated descriptors such as file position and access mode. There are other attributes that belong to a single file descriptor, even when duplicated, such as the close-on-exec flag in GNULib.

Doing a duplicate (either with dup, dup2 or your fcntl) could be a way to create two descriptors, one with different file descriptor attributes, but I can’t see that being the case in your question since the first descriptor is closed anyway. As you say, why not just use the low descriptor?

Interestingly enough, if you google for netconfig f_dupfd, you will see similar traces where the fcntl fails and it continues to read that file with the low descriptor so my thoughts on the matter are that this is an attempt to preserve low file descriptors as much as possible. For example:

4327:   open("/etc/netconfig", O_RDONLY|O_LARGEFILE)    = 4
4327:   fcntl(4, F_DUPFD, 0x00000100)                   Err#22 EINVAL
4327:   read(4, " # p r a g m a   i d e n".., 1024)     = 1024
4327:   read(4, " t s           t p i _ c".., 1024)     = 215
4327:   read(4, 0x00296B80, 1024)                       = 0
4327:   lseek(4, 0, SEEK_SET)                           = 0
4327:   read(4, " # p r a g m a   i d e n".., 1024)     = 1024
4327:   read(4, " t s           t p i _ c".., 1024)     = 215
4327:   read(4, 0x00296B80, 1024)                       = 0
4327:   close(4)                                        = 0

Maybe the software has a byte array of file descriptors somewhere that’s limited so it attempts to move other files above the 255-limit.

But really, that’s just guesswork on my part (although I’d like to think it’s relatively intelligent guesswork). Also keep in mind that it may not be Oracle itself doing this. The netconfig stuff is used in a lot of places so it may be some underlying library doing that, especially in light of the fact that most of the afore-mentioned web hits weren’t Oracle-specific (ftp, remsh and so on).