[PATCH V2 RESEND] win32: improve the performance of win32.unlink() over CIFS
adrian at cadifra.com
Thu Feb 20 09:34:39 CST 2014
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).
> 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 |
(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.
More information about the Mercurial-devel