When will os.remove fail?

[Michael Felt]

On 13/03/2017 02:51, Steve D'Aprano wrote:
> On Mon, 13 Mar 2017 05:45 am, Alain Ketterlin wrote:
>
>> Steve D'Aprano <steve+python at pearwood.info> writes:
> [...]
>>> It seems that os.remove on Linux will force the delete even if the file
>>> is read-only or unreadable, provided you own the file.
>> Your permissions on the file do not really matters. It's all about your
>> permissions on the parent directory (removing a file is really modifying
>> the parent dir). Actually, it is even slightly more complicated. Here is
>> an excerpt of the unlink(2) call (which does the job) listing common
>> error cases:
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.

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.

> Thanks for the detailed explanation, and to everyone else who corrected my
> misunderstanding.
>
>
>