When you fork a process, the child inherits its parent's file descriptors. I understand that when this happens, the child receives a copy of the parent's file descriptor table with the pointers in each pointing to the same open file description. Is this the same thing as a file table, as in http://en.wikipedia.org/wiki/File_descriptor, or something else?
file descriptor → open file description → directory entry
There are several levels of indirection when going from an open file in a process all the way to the file content. Implementation-wise, these levels generally translate into data structures in the kernel pointing to the next level. I'm going to describe a straightforward implementation; real implementations are likely to have a lot more complications.
An open file in a process is designated by a file descriptor, which is a small nonnegative integer. The numbers 0, 1 and 2 have conventional meanings: processes are supposed to read normal input from 0 (standard input), write normal output to 1 (standard output), and write error messages to 2 (standard error). This is only a convention: the kernel doesn't care. The kernel keeps a table of open file descriptors for each process, mapping these small integers to a file descriptor structure. In the Linux kernel, this structure is
The file descriptor structure contains a pointer to an open file description. There can be multiple file descriptors pointing to the same open file description, from multiple processes, for example when a process has called
dup and friends, or after a process has forked. If file descriptors (even in different processes) are due to the same original
open (or similar) system call, they share the same open file description. The open file description contains information about the way the file is open, including the mode (read-only vs read-write, append, etc.), the position in the file, etc. Under Linux, the open file description structure is
The open file description lives at the level of the file API. The next level is in the filesystem API. The distinction is that the file API covers files such as anonymous pipes and sockets that do not live in the filesystem tree. If the file is a file in the directory tree, then the open file description contains a pointer to a directory entry. There can be multiple open file descriptions pointing to the same directory entry, if the same file was
opened more than once. The directory entry contains information about what the file is, including a pointer to its parent directory, and information as to where the file is located. In the Linux kernel, the directory entry is split in two levels:
struct inode which contains file metadata and
struct dentry which keep track of where the file is in the directory tree.
I'm interpreting the question as mainly about terminology, specifically the "file table".
If you look at early implementations, the set of all open file descriptions in the system was an array. When a process needed a new open file description, the array was scanned for an unused slot and a pointer to that slot was returned. See for example
falloc at the bottom of http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/fio.c
In that system, "file table" is a natural name for the system-wide array of
Nowadays, open file descriptions are allocated dynamically with a more flexible mechanism than just choosing an unused slot in a fixed-size array. The set of all open file descriptions in the system is not required to be arranged in a contiguous array-like setup. So there really isn't a "file table" anymore, unless you consider every dynamic memory allocation pool to be a "table".
The "file table" in the diagram on wikipedia is a set of open file descriptions. A file descriptor is an index into an array of pointers to open file descriptions. Since the open file descriptions are always accessed through those pointers, never by numerical index in some array, drawing them as a contiguous column of boxes is a little misleading. And calling it a "table" reinforces that misleading image.
But it's a fairly common usage so I don't expect it to die out soon.
I found the answer in documentation for the open system call:
The term open file description is the one used by POSIX to refer to the entries in the system-wide table of open files. In other contexts, this object is variously also called an "open file object", a "file handle", an "open file table entry", or—in kernel-developer parlance—a struct file. When a file descriptor is duplicated (using dup(2) or similar), the duplicate refers to the same open file description as the original file descriptor, and the two file descriptors consequently share the file offset and file status flags. Such sharing can also occur between processes: a child process created via fork(2) inherits duplicates of its parent's file descriptors, and those duplicates refer to the same open file descriptions. Each open(2) of a file creates a new open file description; thus, there may be multiple open file descriptions corresponding to a file inode.
Trying to understand what your asking because it's not clear. But if I understand properly, your asking how can multiple processes write to the same file? Well in Linux, by default, files are not locked by processes and its always possible for multiple processes to write to the same file. Which of course risks breaking the files formatting. Writes tend to be a buffer at a time (in most cases that means a full line of text, which sort of works ok if the file is a common log and multiple processes are writing to it) though unbuffered files can be used, but that requires extra non-default options to be chosen when the file was opened.
Files that are opened with random IO can really be messed up by being opened by several processes and that sort for IO probably requires file locking to be safely used.
Another related issue, is if a file is held open by a running process, even if the process doesn't write often or at all to that file. The file will continue to take up disk space, even if 'deleted'. Only after the process releases its filehandle by closing the file, will its used disk space be recovered.
Another place to learn more about open files is in the /proc directory, particularly /proc/PID/fd This is a way to see what files a given PID process had held open.