Frequently Asked Question

What happens when I rm a file that another program still has open?

rm does not actually delete a file, it calls the unlink(2) system call, which removes one directory entry and decrements the link count on the inode. The data blocks are only released when two conditions are both met: the link count reaches zero, and no process has the file open. So if your editor or log writer still holds a file descriptor on the file when you delete it, the file vanishes from ls but lives on, invisible, attached to that descriptor.

This is a frequent surprise in production. A daemon writing to /var/log/app.log keeps filling the same inode after you rm the log; disk-free in df keeps shrinking even though du reports nothing in /var/log. The fix is to find the culprit with lsof | grep deleted and either restart the process or instruct it to reopen its log file (sending SIGHUP to most daemons does this). Many programs that want a guaranteed-private scratch file deliberately exploit the behaviour: open a file, unlink it immediately, and the inode is reclaimed automatically the moment the process exits.