5

My understanding is that a file descriptor is an integer which is a key in the kernel's per-process mapping to objects such as open()ed files, pipes, sockets, etc.

Is there a proper, short, and specific name for “open files/sockets/pipes/...”, the referents of file descriptors?

Calling them “files” leads to confusion with unopened files stored in the file system. Simply referring to file descriptors does not adequately describe the semantics (e.g. copying the integer between processes is useless).

Consulting The Open Group Base Specifications and my own system's manpages leads me to the conclusion that the referent of a file descriptor is an object and when it is specifically an open file it is, well, an open file. Is there a more specific term than object?

2 Answers2

8

There is not really a more specific term. In traditional Unix, file descriptors reference entries in the file table, entries of which are referred to as files, or sometimes open files. This is in a specific context, so while obviously the term file is quite generic, in the context of the file table it specifically refers to open files.

Files on disk are often referred to as inodes, although technically the inode is the metadata portion of the file. However since the relationship between the inode and the data blocks is one-to-one, referring to an inode implicitly refers to the data to which it points. More modern filesystems may support features such as copy-on-write where data blocks may be shared, so this is not universally true, but is for traditional Unix. However, given the term filesystem, it is no small leap to consider the contents of that to be files.

inodes are also read into memory as in-core inodes when a file on disk is opened, and maintained in the inode table, but that is one level of indirection further than you are asking.

This leads to the conflict in terminology: files on disk (referenced by an inode), and open files (referenced by entries in the file table).

I would suggest that "open file" or "file table entry" are both adequate descriptions of what you are looking to describe.

One reasonably concise reference I found is at: http://www.hicom.net/~shchuang/Unix/unix4.html. References of the form (Bach nn) are references to the book The Design Of The Unix Operating System by Maurice J. Bach.

camh
  • 39,069
  • I think that on some operating systems "open file" is a specific term that can also include mappings. There's also the fact that, IIRC, "duplicating" a file descriptor doesn't duplicate some things, like the position, so really all you can reasonably call it is "file descriptor table entry" – Random832 Apr 15 '11 at 21:09
  • @Random832: The file descriptor table is separate to the file table. I was specifically referring to the file table, hence called it a "file table entry". But I guess the question could be read either way. – camh Apr 15 '11 at 22:08
1

In 7th Edition Unix, the file descriptor is an index to a table in the user structure which is simply an array of pointers into the [system global] open file table. So the file descriptor itself is really an indirect reference, a 'pointer to a pointer' of sorts. It also indexes an array of one-byte flag fields (which only included, at the time at least, the close-on-exec flag).

struct user {
    ...
    struct file *u_ofile[NOFILE]; /* pointers to file structures of open files */
    char u_pofile[NOFILE]; /* per-process flags of open files */
}

The open file table itself contains the read/write mode a file was opened with, a pointer to the inode, the position, and probably dozens of other things on modern systems. I have no idea if the file descriptor table contains anything more than this on modern systems.

See:

Random832
  • 10,666