This behavior is fairly general to Unix! A cute thing on Linux is that there are also references to open files under /proc, including synthetic kernel-generated filesystem links to the files, even if they've been deleted.
So if you delete a file from the filesystem that's open by PID 12345, you can find a reference to that file still present in /proc/12345/fd, and you can actually make a new copy of the file with cp or something.
And also when deleting a file that's on NFS, but it's reference count is non-zero in the kernel (because at least one process has it open) you end up renaming not deleting the file.
The content of the file remains accessible to the process that has it open and continues to take up disk space.
... and a new file with the same name (and path) and different content can be created that exists at the same time.
This can be confusing.
"I'v updated that file on the server and it has not taken effect. I'v ssh'ed in and I can see the new version. What is going on? If I reboot that box the phone will start ringing..."
A file is held open read only by a process, and then you delete the file. Under memory pressure and without swap, can Linux evict those pages to reclaim memory?
The file's blocks exist in the filesystem. "Those pages" just refers to the ordinary buffer cache for any other disk-based file. No cached pages are necessary to hold open a file on disk.
Well I did not read the article, but here is what I think.
In the old days on an old 16 bit UNIX, I had to execute unlink to delete a file.
So I would say the inode # will be removed from the directory entry, leaving the file in place. So the program will continue on happily. On Linux, I think it depends on the file system. But I think it will continue until the file is overwritten. If the file is closed and re-opened after rm(1), the program will fail.
EDIT: I took the quiz. But I have to wonder if on a fs like zfs/btfs something different will happen.
So if you delete a file from the filesystem that's open by PID 12345, you can find a reference to that file still present in /proc/12345/fd, and you can actually make a new copy of the file with cp or something.
... and a new file with the same name (and path) and different content can be created that exists at the same time.
This can be confusing.
"I'v updated that file on the server and it has not taken effect. I'v ssh'ed in and I can see the new version. What is going on? If I reboot that box the phone will start ringing..."
A file is held open read only by a process, and then you delete the file. Under memory pressure and without swap, can Linux evict those pages to reclaim memory?
In the old days on an old 16 bit UNIX, I had to execute unlink to delete a file.
So I would say the inode # will be removed from the directory entry, leaving the file in place. So the program will continue on happily. On Linux, I think it depends on the file system. But I think it will continue until the file is overwritten. If the file is closed and re-opened after rm(1), the program will fail.
EDIT: I took the quiz. But I have to wonder if on a fs like zfs/btfs something different will happen.