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.

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.

Shame that you can't then link /proc/self/fd/N to a different node in the filesystem namespace. That'd be neat and symmetric.

Followup quizz:

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 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..."