[PATCH 5 of 5] exchange: use file closer when applying stream clones

Adrian Buehlmann adrian at cadifra.com
Wed Sep 30 12:45:29 CDT 2015


On 2015-09-30 19:07, Gregory Szorc wrote:
> On Wed, Sep 30, 2015 at 9:52 AM, Adrian Buehlmann <adrian at cadifra.com
> <mailto:adrian at cadifra.com>> wrote:
[..]
> 
>     I'd like to remark here that holding files open on Windows has
>     consequences in combination with unlinking - as I've noted on
>     https://www.mercurial-scm.org/wiki/UnlinkingFilesOnWindows
> 
>     (just to make sure you are aware of this)
> 
> 
> Thanks for the pointer.
> 
> I reckon this would come into play during transaction rollback? So it
> sounds like we will need some kind of awareness between the transaction
> object and deferred close? Suddenly Augie's suggestion of integrating
> this with the VFS layer sounds like a necessity...
> 

I don't know. I haven't thought through what you are trying here. I just
remembered the nightmares I had with deleting open files on Windows when
I saw what you are doing here.

See for example win32.unlink which has ''try to implement POSIX' unlink
semantics on Windows''' in its docstring. Carefully note the word "try"...

Also, there are adventurous people out there which keep trying to have
their repos on Windows shares, including SAMBA shares. Even though we
keep telling them that this is not recommended...

Traditionally, we also had issues with aggressive virus scanners, which
specifically tend to jump onto freshly created files, adding yet another
process which holds random files open. I think I once saw reports of
especially nasty scanners which exclusively locked files into memory to
inspect them. Not that I would want to say we should support these, but
there all kinds of insane things happening in the wild.

This is not to say that what you are trying here is bad.

Intuitively, I would just try to avoid keeping files open longer than
really needed.


More information about the Mercurial-devel mailing list