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

Adrian Buehlmann adrian at cadifra.com
Thu Feb 20 12:08:00 CST 2014


On 2014-02-20 18:13, Kaz Nishimura wrote:
> To make a file completely deleted, we must have the last open file
> handle.  If we open the file non-exclusively, we cannot assure that and
> must always use slower rename and unlink.  If there is a way to make
> sure we have the last open handle, we can avoid exclusive open totally. 
> Can you suggest any?
> 
> Win32 API is unclear about hard links and the effect of the
> DELETE_ON_CLOSE flag.  If the flag is set and all open handles are
> closed, the file must be deleted according to the description, but if a
> handle is opened from another hard link, nothing is described about what
> happens.  I could be confused.  Apparently the flag must be set on the
> hard link not on the file itself.
> 
> We could add FLAG_SHARE_DELETE to make deletion of other hard links
> possible, but if any file handles with DELETE access might remain too
> long (I think unlikely), the file name (or hard link) can remain longer
> than we want.  Any solution here?

Back then when I wrote

  http://mercurial.selenic.com/wiki/UnlinkingFilesOnWindows

I think I found out a couple of those surprising (and silly..) aspects
by experimenting, not by reading docs. I think especially the amazing
things about hardlinks.

I'm currently not that much interested in using recent versions of
Mercurial, so I can't really help you that much taking decisions here. I
just responded because I was wrestling with these kind of things in the
past. Perhaps you can safely ignore my comments and just keep them in
mind in case problems should appear.


More information about the Mercurial-devel mailing list