On Wed, Mar 15, 2017 at 5:28 AM, Michael Felt <mich...@felt.demon.nl> wrote: > Granted, I am a bit behind in the discussion - and I know nothing about how > Windows manages this since DOS 3.3 - there it also called unlink(). > > rm is the command we run. The system call it uses to remove a file is > unlink(). unlink() removes the "link" of the name in the directory to the > inode and lowers the count of the number of links to the file (a hard link > is an additional directory link to the inode). To modify the inode (link > counter) you need to own the file or have (super user) elevated privelidges. > To remove the directory link you need to have write privilidge on the > (special file type) directory. > > On UNIX/Linux when the link count is zero the inode and the filesystem > blocks it provides access to are cleared if no process is holding the file > open. This means it is easy to unlink() (not remove!) an open file. The > inode is active and can be used "normally". FYI, the classic mktemp() > library routine on UNIX would create a file, open (better create) the file, > unlink the file, and then return file descriptor. Regardless of how the > program ended (crash or normal) the temp file would be cleaned up on exit.
You've fairly accurately summed up the POSIX model. The rm command uses the unlink syscall, and the semantics are broadly as you describe; the permissions question is handled by the standard permission bits "rwxrwxrwx", but otherwise you're about right. And yes, removing a file means removing one name from it, which is why a log file growing to infinity can't simply be deleted when you run out of disk space. If the program ends while the OS is still alive, then yes, the temp file will be cleaned up on exit. If the power is pulled, AIUI a fsck will notice that there's a file with no directory entries, and clean it up, although it may end up dropping it into lost+found rather than just deleting it. > I would be guessing - but FAT and/or NTFS may not be written to clean up on > a file with no "links" - and this is why Windows behavior seems to be more > restrictive than POSIX/LINUX. The Windows semantics are very different. Firstly, FAT doesn't even _have_ the concept of hardlinks (aka files with multiple directory entries), so there's no way that it'll ever be able to do this kind of thing. (And before you say "oh but FAT is dead these days", it's still frequently used on removable media.) NTFS does have hardlinks, so in theory it would be capable of POSIX semantics, but Windows semantics are baked into a lot of programs' expectations, so I doubt that that's going to change. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
