You&#x27;d be hard pressed to convince me that Windows model for locking files is superior to what Unix offers, at least as far as file deletion goes. Conceptually speaking, it&#x27;s pretty simple:<p>* Files are blobs of storage on disk referenced by inode number.
* Each file can have zero or more directory entries referencing the file. (Additional directory entries are created using hard links.)
* Each file can have zero or more open file descriptors.
* Each blob has a reference count, and disk space is able to be reclaimed when the reference count goes to zero.<p>Interestingly enough, this means that &#x27;rm&#x27; doesn&#x27;t technically remove a file - what it does is unlink a directory entry. The &#x27;removal&#x27; of the file is just what happens when there are no more directory entries to the file and nothing has it open.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;dspinellis&#x2F;unix-history-repo&#x2F;blob&#x2F;Research-V7-Snapshot-Development&#x2F;usr&#x2F;src&#x2F;cmd&#x2F;rm.c#L110" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dspinellis&#x2F;unix-history-repo&#x2F;blob&#x2F;Researc...</a><p>In addition to letting you delete files without worrying about closing all the accessing processes, this also lets you do some useful things to help manage file lifecycle.  ie: I&#x27;ve used it before in a system where files had to be in an &#x27;online&#x27; directory and another directory where they were queued up to be replicated to off-site storage. The system had a directory entry for each use of the file, which avoided the need to keep a bunch of copies around, and deferred the problem of reclaiming disk storage to the file system.