When will os.remove fail?

[Chris Angelico]

On Wed, Mar 15, 2017 at 5:28 AM, Michael Felt <michael at 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