After posing this question, I'm kind of confused by the action of the linxu kernel.
First of all, I know how a process writes strings into a file: a process will obtain some buffer, the buffer can be written by the process, once the buffer is full or the process flushes the buffer, the content of the buffer will be written into the data block of the file. For example, in the program of C, when we printf
a \n
, it will flush the buffer.
Now, let's consider the case in the post above: a process has opened a file and is writing to it while the file is deleted by the comomand rm
.
As my understanding, the command rm
will unlink the file, meaning that its inode and its data blocks will be marked as UNUSED
. So we can't access it through the filename anymore. And if a process opens a file, the kernel will create a file descriptor to access it.
So if I'm right, rm
a file, to which a process is writing, won't cause any error of the process, because the process could access the file through the file descriptor. As someone mentioned in the comment of that post, we can still access the file through cat /proc/<pid>/fd/3
.
Now I'm confused. If we can still access the file through cat /proc/<pid>/fd/3
while the inode and the data have been marked as UNUSED
because of rm
, does it mean that the kernel will hold the whole file in RAM? If so, if the file is very huge, such as some log file, does it mean that lots of RAM will be used?
In a word, if a file isn't rm
ed, a process can write things into the buffer and once the buffer is flushed, its content will be written into the data blocks of the file. But if a file has been rm
ed, its data blocks will be marked as UNUSED
but a process can still write to it. Where is this "it"?
rm
will actually unlink the file like it would under normal circumstances. A couple of years ago, I ram some tests on this, and if I recall correctlyrm
will only unlink the file in "totallity" ,if and only if, all file descriptions from other processes stop first. Commandlsof
is used to check for these handles on files, especially if there is a large file to delete to reclaim space, which cannot be done until terminating all corresponding handles.<unused>
inlsof
output but <deleted> i.e. to check for locked deleted files I was taught to dosudo lsof | grep delete
as that will show files that are "seemingly deleted", but still have their file descriptor held by another process with listed PID. Your file doesn't actually get touched until the linked processes terminate. The file isn't actually held in RAM (unless it is a RAM based system) but instead can have a web of links connected to it. Only when all of them (from various processes) are cut does the file fall into the abyss.rm
the file?file1
. If we first "hold" the file through another processnano file1
for exe, followedrm file1
, then get PID ofnano
withlsof | grep file1| awk '{print $2}'
, and find it withfind /proc/PID -type f -exec ls -l {} | grep file1 \;
, (the-exec
part may need work) and finallycp /proc/PID/[pathoffile] temp1
will bring thefile1
back