NTFS and hardlinks

[Matt Harbison]

On Fri, 22 Dec 2017 18:39:50 -0500, Adrian Buehlmann <adrian at cadifra.com>  
wrote:

> On 2017-12-22 23:39, Matt Harbison wrote:
>> I forgot about this, but e506e461c7a9 disabled hardlinks unless the
>> filesystem is in a whitelist.  NTFS isn't in that list, and Windows
>> doesn't implement osutil.getfstype().  I thought the issue was only CIFS
>> (see issue4546).  It looks like it's just a matter of calling
>> GetVolumeNamePath(), GetVolumeInformation(), and doing the bytes -> wide
>> char dance.  (Are we assuming the path bytes are UTF-8?)  Is there an
>> issue here I'm not aware of, or is this doable?
>>
>> The reason I ask is I just stumbled upon util.copyfile(), which holds  
>> this
>> whitelist.  lfutil.link() doesn't know anything about the whitelist, and
>> will happily create hardlinks anywhere.  I tried having lfutil.link()  
>> call
>> util.copyfile(), but that broke several lfs and largefile tests.  They
>> should be conditionalized, but I'd rather not lose the ability to run
>> these tests on Windows.  (Most of the lfs verification stuff I submitted
>> yesterday doesn't get a corrupt file to choke on when full copies are
>> done.)
>
> Did you see util.copyfiles? (note the 's' at the end).
>
> copyfiles looks like it is still linking files on Windows, which I think
> is fine and needed for e.g. local cloning.

Thanks for the pointer.

I tried that, and it works, except the last test in  
test-largefiles-small-disk.t does end up with a file other than dirstate.   
It looks like mq.qsave and hg.copystore are the only things to use it.  If  
it is safe to create hardlinks unconditionally between the repo largefile  
store and the usercache, then the existing code is fine.  I just thought  
maybe this was overlooked.