Before you say Linux files, look at the Linux file system. Although the implementation details are different, the approximate organization of the file system is as follows:
Local amplification:
From the above two diagram is visible, for each file has an I node corresponding to, this is the Linux file system to the file and file information abstracted separately, the file information is stored on the I node (I node length fixed, content including file type, file Access License, The length of the file and pointers to the data blocks used by the file, but not including the file name, can be called by the System Stat (2), FStat (2), LStat (2) are obtained. I have too many nodes to improve the search efficiency, the kernel is sometimes indexed by a hash. The file is saved in the data block area.
It can also be seen that there can be moreA directory entry points to the same I node. Essentially, each I node has a connection count (a hard connection) that is deleted only if the number of directory entries that point to the I node is reduced to 0 o'clock, and the corresponding data block is freed. The purpose of a hard connection is to allow a file to have multiple valid pathname names. BTW:Another symbolic connection (symbolic link), also known as a soft connection. The soft Connect file has a shortcut similar to Windows. It's actually a special file. In a symbolic connection, a file is actually a text file that contains location information for another file. It has its own I node, the file type in the I node is s_iflnk, so the system knows that this is a symbolic connection. When we delete the source file, the linked file cannot exist independently, although the file name is still preserved.
In addition, in Linux, the directory is also a file, it usually contains only the file name list and I node location information, I node 1267 points to the directory created subdirectory TestDir (inode2549):
From the diagram, any directory, the connection count is at least 2
Next, look at the data structure of the kernel processing I/o:
The process table entry exists in each process, the file table entries are maintained for each open file, where the file status flags include read, write, add write, synchronous, non-blocking, etc., the V node can be understood as the above I node, different system implementation details slightly difference. Two separate processes when opening the same file (same process open two times similar):
Note the fork difference, after fork, the parent and child processes share the same file table entry for each open file descriptor
Copy of the file descriptor:
#include <unistd.h> int dup (int oldfd); int dup2 (int oldfd, int newfd)
The new file descriptor returned by the DUP must be the smallest value in the currently available file descriptor. With dup2, you can specify the value of the new descriptor with the NEWFD parameter. If the NEWFD is already open, turn it off first. If OLDFD equals NEWFD, it returns NEWFD without closing it. But both of them are atomic operations. For example, after executing DUP (4,1), the kernel data structure is as follows:
Because two descriptors point to the same file table entry, they share the same file status flags (read, write, add-write, and so on) and the same current file offset.
If you want to recover after replication, it is common practice to back up NEWFD with a save_fd. Like what:
SAVE_FD = DUP (Stdout_fileno);d up2 (FD, Stdout_fileno), Close (FD), write (Stdout_fileno, MSG, strlen (msg));d up2 (SAVE_FD, Stdout_fileno); write (Stdout_fileno, MSG, strlen (msg)); close (SAVE_FD);
Process
Note: The 3rd picture, to execute dup2 (FD, 1), the file descriptor 1 originally pointed to the TTY, now to point to the new file Somefile, the original closed, but TTY this file originally has two reference count, and the file descriptor SAVE_FD also point to it, So just subtract the reference count by 1 and not really close the file.
The 5th picture, to execute dup2 (SAVE_FD, 1), the file descriptor 1 originally pointed to somefile, now to point to the new file TTY, the original closed, Somefile originally only a reference count, so this time reduced to 0, is really closed.
