[PATCH V2 RESEND] win32: improve the performance of win32.unlink() over CIFS

[Adrian Buehlmann]

On 2014-02-20 13:22, Kaz Nishimura wrote:
> 
> On Thu, Feb 20, 2014 at 8:02 PM, Adrian Buehlmann <adrian at cadifra.com
> <mailto:adrian at cadifra.com>> wrote:
> 
>     On 2014-02-19 23:03, Matt Mackall wrote:
>     > On Mon, 2014-02-17 at 12:02 +0900, Kaz Nishimura wrote:
>     >> # HG changeset patch
>     >> # User Kaz Nishimura <kazssym at vx68k.org <mailto:kazssym at vx68k.org>>
>     >> # Date 1381984037 -32400
>     >> #      Thu Oct 17 13:27:17 2013 +0900
>     >> # Node ID 95a976e04589e3d33f69805dff56a249bee250ae
>     >> # Parent  0e2877f8605dcaf4fdf2ab7e0046f1f6f80161dd
>     >> win32: improve the performance of win32.unlink() over CIFS
>     >
>     > Queued for default, thanks.
>     >
> 
>     Perhaps this is worth the risk.
> 
>     Let me just note that opening a file in exclusive mode possibly prevents
>     deletion of other hardlinks to this file for as long as the file is
>     held open.
> 
>     As per the comment in win32.unlink:
> 
>         # - Calling os.unlink (or os.rename) on a file f fails if f or any
>         #   hardlinked copy of f has been opened with Python's open().
>     There is no
>         #   way such a file can be deleted or renamed on Windows (other than
>         #   scheduling the delete or rename for the next reboot).
> 
>     and:
> 
>       http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows
> 
> 
> This patch closes the file handle immediately after we successfully open
> the file exclusively for deletion, so the file does not stay open so
> long and I hope we can ignore the chance that another process tries to
> delete other hard links to the same file at the same time.  Even if it
> could happen, it would not be so worse as any other processes might have
> open handles for the file anyway, in which case DeleteFile could also
> fail to delete the file.

(please don't top post)

On Windows, Mercurial - in general - opens files with

  			    FILE_SHARE_READ | FILE_SHARE_WRITE |
			    FILE_SHARE_DELETE,

(see call to CreateFile() API in osutil.c on line 534)

So no, Mercurial in general deliberately opens files in a way which allows
rename and delete while the file is open (by another Mercurial process).
We did this for a reason.

What you (possibly) introduced now is an - albeit - small chance that another
process, which is trying to delete a hardlink, will fail.