John Hasler wrote:
hendrik writes:I thought that a deleted file that was still being read *was* unlinked from the directory, just not removed from the disk until it was closed.The directory entry is deleted and the link count is decremented when the file is deleted from the directory. When the file was opened the link count was incremented, so this does not bring it to zero. When the file is closed the link count is decremented. If this brings the link count to zero the file is deleted.
First, HdV has discovered his problem is directory structure corruption. This is the correct answer, based on all the failed attempts to remove, in one way or another, this file.
I'd like to clarify what has been said by John (above) and others, for future reference. Note this is my understanding and interpretation, based on reading M. Bach's "The Design of the UNIX Operating System", and other texts.
Every file stored in a file system (UNIX style, at least) has an entry in a directory, a pointer to an inode, an inode and some data blocks. When created, the link count (it's a *hard* link, by the way) is one. If you use 'ln' to create additional hard links to the file, the link count is incremented *and* a new directory entry is made with the same inode pointer as the source file.
When you delete a 'file', the directory entry and pointer are cleared, and the link count in the inode is decremented.
Deleting a file with a link count of 1 will cause the link count to go to zero (duh ;), resulting in deallocation of the inode as well as removal of the name and inode pointer from the directory. If no application has the file open, the data blocks are also deallocated.
If the file is open, the kernel has an 'in kernel memory' copy of the inode and a file descriptor, assigned to the application that has the file open. In this case, the data blocks are not deleted until the application exits and releases the file descriptor. At that point, the in kernel inode becomes invalid, and the data blocks are deallocated. This is similar to but still distinct with respect to the on disk inode. Put another way, the internal inode has both a count of 'links' and a count of 'file descriptors', and the deallocation only happens when both go to zero.
John (and others) did(have) not make this distinction between in memory inodes and disk inodes, which I think is critical to understanding how the kernel deals with files and file systems.
Bob
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature