[PATCH 0 of 3 STABLE] break hardlinks for open files

Adrian Buehlmann adrian at cadifra.com
Thu Dec 2 00:37:02 CST 2010


On 2010-12-02 01:31, Matt Mackall wrote:
> On Wed, 2010-12-01 at 13:53 +0100, Adrian Buehlmann wrote:
>> This series fixes issue2524 by dealing with Windows'
>> "scheduled delete" state as described on
> 
> I'm afraid I don't have enough time to review these for 1.7.2.

Yeah, I'm a bit late. Maybe it's even a story for 1.8.

It took me some time to understand the implications of scheduled delete.

Now I understand why Windows needs to be rebooted that often...

> My first reaction is util.unlink should be made to work regardless of
> platform.
> 

Maybe.

Thing is, util.unlink probably does too much to be used here, since it
also tries to remove directories (which won't work anyway for files in
scheduled delete).

IMHO, the opener -- as it is -- swallows too many exceptions in too many
cases.

The very harmful behavior of Windows (not just for files on shares) is
that if you delete a file that happens to be opened (using posixfile),
Windows will put the file in a special state (I've called it "scheduled
delete") which blocks recreating the file under the same name again for
as long as the file is held open by any process. Even calling lstat on a
name that is this state will raise an exception.

If the file was opened with plain open(f), deleting and renaming that
file is blocked completely, os.unlink will raise an exception right
away. Same for os.rename.

The opener refactoring we did for 1.7.1 made matters worse due to the
double unlink on 'w'rite for the localrepo.wwrite code path, although
Mercurial <=1.7 already failed to correctly cope with scheduled delete too.

I think if we manage to get this story right, we will probably also
improve robustness against the ubiquitous on-access scanners on windows.



More information about the Mercurial-devel mailing list