The file name in the Linux system is stored in the block of the parent directory, and points to the inode node of the file, and the inode node of the file points to the block data block that stores the file.
When we delete a file, we don't actually clear the inode node and block data block. Just delete the name of the file in the block in the parent directory of the file, so that the file name disappears and cannot point to the inode node of the file.
When there is no file name pointing to the inode node, the inode node and the block data block storing the file will be released at the same time, and the inode MAP and block MAP will be updated so that these locations can be used to place other file data in the future.
Variables controlled by file deletion:
i_link number of hard links to the file
i_count reference count
When creating a hard link to a file, the corresponding i_link count is incremented. When a file is referenced by a process, the corresponding i_count will increase.
For the delete command rm, it is actually reducing i_link. So what happens if a file is being called by a process and the user performs an rm operation to delete the file?
After the user executes rm to operate the file, and then executes ls or other file management commands, the file can no longer be found, but the process calling the deleted file continues to execute, and can still read and write content correctly from the file. ,what about this?
This is because the rm operation only reduces i_link. If there are no other links, i_link will be 0, but since the file is still referenced by the process, the i_count corresponding to the file is not 0, so even if the rm operation is performed, the system does not This file is not really deleted. When only i_link and i_count are 0, this file will be really deleted. That is to say, it is necessary to release the process's call to this file.
Then when the file is not called, can the deleted file be retrieved after the rm operation is performed to delete the file?
The rm operation only reduces the i_link of the file, but actually deletes the link from the file name to the inode. Even if i_link is reduced to 0, the entity (block data block) of the file is not deleted at this time. At this time, if the machine is stopped, the data can be retrieved. If the data continues to be written at this time, the new data may be allocated to the deleted block data block. At this time, the file will be truly recycled. .