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?