[PATCH 7 of 7 V3] util: enable hardlink for copyfile

Mads Kiilerich mads at kiilerich.com
Sun Mar 12 14:48:35 EDT 2017

On 03/12/2017 11:03 AM, Augie Fackler wrote:
> On Sun, Mar 12, 2017 at 11:00:05AM -0700, Mads Kiilerich wrote:
>> On 03/12/2017 01:23 AM, Jun Wu wrote:
>>> # HG changeset patch
>>> # User Jun Wu <quark at fb.com>
>>> # Date 1489309403 28800
>>> #      Sun Mar 12 01:03:23 2017 -0800
>>> # Node ID 9da40a9e54c419490a2ff23b9dda7acc109f81cd
>>> # Parent  de28b62236a7d47a896bc4aba2bd95dcd8defc87
>>> # Available At https://bitbucket.org/quark-zju/hg-draft
>>> #              hg pull https://bitbucket.org/quark-zju/hg-draft -r 9da40a9e54c4
>>> util: enable hardlink for copyfile
>>> Because why not, if we are sure that the filesystem has good hardlink
>>> support (and we are - see "posix: implement a method to get filesystem type
>>> for Linux").
>>> This patch removes the global variable "allowhardlinks" added by "util: add
>>> allowhardlinks module variable". Third party extensions wanting to enable
>>> hardlink support unconditionally can replace "_hardlinkfswhitelist".
>> How about using the approximation that all case sensitive filesystems are
>> safe to try to use hardlinks? Or to be kind to macOS: All filesystems that
>> support symlinks?
>> e5ce49a30146 was a last minute change and *very* safe, disabling it on all
>> platforms.
>> It seems like the problem only is seen when running Windows on the client
>> side - perhaps only disable these hardlinks on Windows? It seems like there
>> really is no need for detecting any file systems on Linux?
> It's actually believed the problem is in the Windows CIFS *server*, if
> you read the bug attached to the previous change.

I only see mentioning of problems with Windows on the client side. 
Matt's theory of the source of the cache coherency issue suggested that 
it was interaction between client and server side caches. Non-windows 
client side implementations may or may not have the same problem, but I 
see nothing suggesting they have.

That might of course be because most users of repos on CIFS are Windows 
users. The problem is serious when it happens, but considering the 
non-Windows uncertainty, the small amount of non-Windows users using 
CIFS repos, and the negative impact on all non-Windows users, it might 
be justified to be less conservative for non-Windows.


> I'm hesitant to turn on hardlinks at all because of the way problems
> manifest (unrecoverable data corruption for users, at some random
> point in the future), so if we're going to do it we need to be very
> conservative to avoid the bug again.
>> The infrastructure for detecting file system seems cool, but also quite low
>> level and high-maintenance for each platform. If we need to detect CIFS,
>> could we perhaps just detect CIFS through generic file system operations
>> instead of whitelisting everything that isn't CIFS?
>> /Mads

More information about the Mercurial-devel mailing list