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+pyt...@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.
--
https://mail.python.org/mailman/listinfo/python-list
