The kernel uses three data structures to represent open files, and the relationship between them determines the possible impact of one process on another in terms of file sharing. The three data structures are described as follows:
(1) Each process has an entry in the process table, and the entry contains a file descriptor table, which can be regarded as a vector, and each descriptor occupies one entry , associated with each descriptor are:
a. a file descriptor flag;
b. a pointer to a file table entry.
(2) The kernel maintains a file table for all open files, and each file table entry contains:
a. File status flags (read, write, append, synchronous, non-blocking, etc.);
b. Current file offset;
c . Pointer to the v-node table entry for this file.
(3) Each open file (or device) has a v-node (v-node) structure (Note: Linux does not use v-nodes, but uses a general i-node structure. Although the two implementations are different, in Conceptually the same, both point to filesystem-specific inode structures). It contains the file type and pointers to various functions that operate on this file. For most files, the v-node also contains the file's inode (i-node, inode). This information is read into memory from disk when the file is opened, so all information about the file is readily available. For example, the inode contains the owner of the file, the length of the file, a pointer to where the actual data blocks of the file are located on disk, and so on.
Here, we ignore those implementation details that do not affect the discussion. For example, the open file descriptor table can be stored in user space (as a separate per-process structure that can be swapped out), rather than in the process table. These tables can also be implemented in various ways, either as arrays or as linked lists of structures. The following figure shows the relationship between the three tables corresponding to a process. The process has two different open files: one is opened from standard input (file descriptor 0) and the other is opened from standard output (file descriptor 1).
According to this table, when two independent processes open the same file, there will be a relationship similar to the following figure.
Here, each process that opens the file gets its own file entry (there may also be multiple file descriptor entries pointing to the same file entry, such as when using the dup function, and the same thing happens after fork, At this point, each open file descriptor of the parent process and the child process shares the same file table entry), so that each process has its own current offset to the file, but only one for a given file. v Node table entry.
After these data structures are given, further explanations can be made.
* After each write, the current file offset in the file table entry is incremented by the number of bytes written. If this causes the current file offset to exceed the current file length, the current file length in the inode table entry is set to the current file offset (that is, the file is lengthened).
* If a file is opened with the O_APPEND flag, the corresponding flag is also set to the current state flag of the file table entry. Each time a write operation is performed on such a file with the append write flag, the current file offset in the file table entry is first set to the file length in the inode table entry. This causes each write to be appended to the current end of the file.
* If a file is located to the current end of the file with lseek, the current offset in the file entry is set to the current file length in the inode entry.
* The lseek function only modifies the current file offset in the file table entry, and does not perform any I/O operations.
A final note is the difference in scope between the file descriptor flags and the file status flags, the former being applied to only one descriptor of a process, while the latter being applied to all processes in any process pointing to that given file entry Descriptor.