What happens to the files that are deleted while they have a file handle open to them?

I have been wondering this ever since I figured out I could delete a video file while it was playing in MPlayer and it would still play through to the end. Where is it pulling the data from? Is it still coming from the hard drive? Did it get copied to RAM once I deleted the file?

If it's still on the hard drive, what happens if I fill up the file system while the program is running reading from what is essentially unallocated space? If it's buffered in RAM, what happens if I flush the buffers?

What happens if the file was on an NFS share–is it stored on the server? (Isn't that a security risk–DoS by tons of open remote file handles?)

Doing an lsof -n |grep '(deleted)' sometimes yields interesting results; if I'm upgrading packages that swap out shared library files, then running programs that had been using those libraries will still be able to use them as if nothing changed.

Bonus question: Is there some way to get the data back from the dead in this situation?

3 Answers 3


The inodes still persist on disk, although no more hard links to the inodes exist. They will be deleted when the file descriptor is closed. Until then, the file can be modified as normal, barring operations that require a filename/hard link.

debugfs and similar tools can be used to recover the contents of the inodes.

  • 10
    This is correct, however if the file is still open, you can get it back by going to /proc/<PID>/fd where PID is the pid of a program that has the file still open. This directory contains all the open file descriptors of the program, and you can access them just like normal files, so you could create a hard link to 'restore' the file.
    – phemmer
    Commented Dec 18, 2011 at 4:44
  • Do note that /proc is Linux-specific (as is debugfs). Commented Dec 18, 2011 at 4:46
  • 1
    Solaris has a /proc as well and the technique works there just fine. Dont know about BSD.
    – phemmer
    Commented Dec 18, 2011 at 4:50
  • 2
    I just have to add that this is awesome.
    – nopcorn
    Commented Dec 18, 2011 at 5:07
  • 1
    @Patrick: You cannot create a hard link to 'restore' a file from /proc. Hard-links work only on the same filesystem, not across filesystems and since /proc is a separate non-writable filesystem you cannot create hard links on it. You could copy the file off /proc though.
    – camh
    Commented Dec 19, 2011 at 7:12

The kernel does reference counting on references to the inode. See my answer to What happens when I close() a file descriptor?.

Deleting open files is likely no more effective a DOS mechanism than just opening files. The ulimit on open files provides some protection against this DOS attempt. It applies to all open files, deleted or not.


A file is only erased on the filesystem once every reference to it has disappeared. Both names and open handles count as references. As long as the file is open in a program, it is not deleted, although most systems don't allow you to recreate a name for it.

The data is still on the drive, but the file is marked as having a link count of 0. If the system crashes, fsck on the next reboot knows that it must delete the data. This doesn't lead to a denial of service any more than a non-deleted file does.

You cannot recreate a link to the file on a stock Linux system as far as I know (short of bypassing the filesystem driver with debugfs or similar methods), but you can recover the contents easily: cat /proc/12345/fd/42 where 12345 is the process ID that has the file open and 42 is the file descriptor number.

Over NFS, when you delete a file that's still open in some client, the NFS server renames the file on the server but does not delete it until all clients have released the file. In my experience, the new name is .nfs…, though I don't know if the name is the same in all NFS implementations.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .