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

Kaz Nishimura kazssym at vx68k.org
Thu Feb 20 06:22:55 CST 2014


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.



On Thu, Feb 20, 2014 at 8:02 PM, Adrian Buehlmann <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>
> >> # 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140220/62c18636/attachment.html>


More information about the Mercurial-devel mailing list