Windows: hardlink support is broken on shared drives

[Patrick Mézard]

Le 17/08/10 20:10, Matt Mackall a écrit :
> On Tue, 2010-08-17 at 19:49 +0200, Patrick Mézard wrote:
>> Le 17/08/10 16:32, Matt Mackall a écrit :
>>> See this thread:
>>>
>>> http://mercurial.markmail.org/thread/4hvungefkgmq3cum
>>>
>>> And this bug:
>>>
>>> http://mercurial.selenic.com/bts/issue761
>>>
>>> If we remotely commit to a repo that has hardlinks because it was
>>> locally cloned, we get a mess in the clone. So we either need to:
>>>
>>> a) figure out how to reliably get an accurate link count over the wire
>>>
>>> or 
>>>
>>> b) figure out how to detect we're on a network share and assume
>>> -everything- is a linked file when committing (slow!)
>>>
>>>
>>> Even something as drastic as disabling hardlink support is insufficient
>>> because there will still be repos with hardlinks on many users' systems.
>>>
>>> I've upped the priority on this bug to critical - we've gotten several
>>> reports of it that we've failed to properly identify the cause of.
>>>
>>> The interesting code bits are here:
>>>
>>> http://www.selenic.com/hg/file/0b84864d1325/mercurial/win32.py#l23
>>>
>>> http://www.selenic.com/hg/file/0b84864d1325/mercurial/win32.py#l53
>>
>> And the interesting quote from:
>>
>>     http://msdn.microsoft.com/en-us/library/aa364952%28VS.85%29.aspx
>>
>> "Depending on the underlying network features of the operating system
>> and the type of server connected to, the GetFileInformationByHandle
>> function may fail, return partial information, or full information for
>> the given file."
> 
> So that gives us three cases:
> 
> a) works - return real nNumberOfLinks
> b) partial - pretend there are 2 to force link breaking
> c) fails - pretend there are 2 to force link breaking
> 
> The trick is to distinguish case (a) from (b). If nNumberOfLinks > 1,
> then we can assume it worked. But we'll probably have to look at other
> fields in the structure to sanity-check it in other cases. But we're
> going to need people with Windows (ie not me) to do some testing with
> different setups to figure out if we can actually reliably detect case
> (b).
> 
> Step one here is probably to write a test script that people can run to:
> 
> a) create a hardlink
> b) report the result details of GetFileInformationByHandle

Test script attached.

It implements two commands:

$ python testlink.py a linka => hardlink linka from a
$ python testlink.py linka => display linka links count (=2) and the volume serial number

Here are the links count and volume serial number when testing a local or remote hardlink.

setup                                      links  serial
-----                                      -----  ------
WinXP local NTFS                           2      != 0               
OSX from WinXP through Parallels           1      == 0
WinXP from Win2003 through RDP             2      != 0
Win2003 local NTFS                         2      != 0
Win2003 from Win2003 through mounted dir   1      == 0

(interesting that a dir mounted through RDP works better than a regular mounted dir...)

At least in these cases, testing serial == 0 would tell us if we can trust the GetFileInformationFromHandle() call.

Patches will follow.

--
Patrick Mézard





-------------- next part --------------
A non-text attachment was scrubbed...
Name: testlink.py
Type: text/x-python-script
Size: 2055 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100817/45f9bd4a/attachment.bin>