D588: win32: use fewer system calls for unlink()

[abuehl (Adrian Buehlmann)]

abuehl added a comment.


  In https://phab.mercurial-scm.org/D588#9925, @quark wrote:
  
  > I can confirm `os.unlink` may succeed without actually removing the file:
  >
  >   >>> from mercurial import util
  >   >>> f=util.posixfile('c:\\users\\quark\\a.txt', 'w')
  >   >>> os.unlink('c:\\users\\quark\\a.txt') # success, but file is still there
  >   >>> f.close() # removes the file
  >   
  >
  > There is a proposed `boost.afio` that seems to take a same approach: https://boostgsoc13.github.io/boost.afio/doc/html/afio/FAQ/deleting_open_files.html
  
  
  (finally created a login to this phabricator madness.. argh).
  
  Yep. You just redescovered what is already known.
  
  The bad thing is, the "zombie file" (can be held open by another process, even by opening any hardlinked name to the same file) makes it impossible to **create a new file under the same name** after "unlinking" the previous one. For as long as the other process holds the "unlinked" file open.
  
  Awesome pointer, BTW!
  
  I'll quote the interesting part found on that link you posted:
  
  > AFIO works around these un-POSIX file semantics by taking a dual step to deleting files. Firstly, it renames the file to a 128 bit cryptographically strong random name prefixed by “.afiod” into as high up the directory hierarchy as it is able to, and only then does it request the deletion of the file. As AFIO always opens files with FILE_SHARE_DELETE permission enabled, with that flag Windows permits renaming and deletion, and because the name was changed to a very random name somewhere not in its origin directory before deletion, you don't see those unexpected and random errors when creating files with the same name as a recently deleted file as you do anywhere else on Windows. Because the file is probably not in its original containing directory any more, deletions of that directory will not fail with “directory not empty” as they otherwise normally would and indeed do in most Windows programs. Handy eh?
  
  Very handy indeed and we already do something similar on Mercurial. We don't rename the "zombie file" to a different directory though, which sounds pretty clever. We could steal that trick from AFIO for Mercurial.
  
  For manual tests: I usually opened the file with an other process to match the scenario we were facing back then when we introduced the "rename to a random name before unlinking" dance.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D588

To: indygreg, #hg-reviewers, quark
Cc: abuehl, durin42, quark, mercurial-devel