Hi I have many files that have been deleted but for some reason the disk space associated with the deleted files is unable to be utilized until I explicitly kill the process for the file taking the disk space

$ lsof /tmp/
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF      NODE NAME
cron     1623 root    5u   REG   0,21        0 395919638 /tmp/tmpfPagTZ4 (deleted)

The disk space taken up by the deleted file above causes problems such as when trying to use the tab key to autocomplete a file path I get the error bash: cannot create temp file for here-document: No space left on device

But after I run kill -9 1623 the space for that PID is freed and I no longer get the error.

My questions are.

why is this space not immediately freed when the file is first deleted?
what is the best way to get back the file space associated with the deleted files?

and please let me know any incorrect terminology I have used or any other relevant and pertinent info regarding this situation.

Best Answer

On unices filenames are simply pointers that point to the memory where the file is based this can be a hard drive or even a ram-backed filesystem Each file records the number of links to it: the links can be either the filename (plural, if there are multiple hard links to the same file), and also every time a file is opened, the process actually holds the "link" to the same space.

The space is physically freed only if there are no links left (therefore, it's impossible to get to it). That's the only sensible choice: while the file is being used, it's not important if someone else can no longer access it: you are using it and until you close it, you still have control over it - you won't even notice the filename is gone or moved or whatever. This is even used for tempfiles some implementations create a file and immediately unlink it so that it's not visible in the filesystem but the process that created it uses it normally Flash plugin is especially fond of this method: all the downloaded video files are held open, but the filesystem doesn't show them.

So, the answer is, while the processes have the files still opened, you shouldn't expect to get the space back. It's not freed, it's being actively used. This is also one of the reasons that applications should really close the files when they finish using them. In normal usage you shouldn't think of this space as free and this should also not be very common at all - with the exception of temporary files that are unlinked on purpose there should really not be any files that you would consider to be unused but still open Try to review if there is a process that does this a lot and consider how you use it, or just find more space.