4 comments

  • schoen 49 minutes ago
    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.

    • cduzz 40 minutes ago
      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.
  • tux3 45 minutes ago
    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?

    • ButlerianJihad 28 minutes ago
      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.
      • tux3 10 minutes ago
        Correct! It's still an inode, even without a path.
  • quotemstr 45 minutes ago
    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.
  • jmclnx 48 minutes ago
    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.