[PATCH 2 of 2 STABLE] store: add auto detection for hardlink count blindness (issue1866)
Adrian Buehlmann
adrian at cadifra.com
Sun Oct 31 19:26:12 UTC 2010
On 31.10.2010 19:40, Matt Mackall wrote:
> On Sun, 2010-10-31 at 08:32 +0100, Adrian Buehlmann wrote:
>> # HG changeset patch
>> # User Adrian Buehlmann <adrian at cadifra.com>
>> # Date 1288506284 -3600
>> # Branch stable
>> # Node ID 6ab76f943954901b6473eb95c00ba673da2f2dd6
>> # Parent cd9700552b22bf12b375fc48a582fd96da721145
>> store: add auto detection for hardlink count blindness (issue1866)
>>
>> The Linux CIFS kernel driver (even in 2.6.36) suffers from a hardlink
>> count blindness bug (lstat() returning 1 in st_nlink when it is expected
>> to return >1), which causes repository corruption if Mercurial running
>> on Linux pushes or commits to a hardlinked repository stored on a windows
>> share, if that share is mounted using the CIFS driver.
>
> Not sure if we're going to get this into 1.7. I had about an hour to
> play with it on Friday night and ran into the following issues:
>
> - op.linktest is weird - when do we ever not want to break hardlinks
> correctly?
I was trying to avoid inflicting the hardlink blindness test on openers
that are used for accessing places where we know mercurial by itself
does not create hardlinks (e.g. the working copy).
Leaving op.linktest at it's default will make the opener behave as it
does today: blindly trust nlinks() and go damage files if nlinks() gives
wrong answers.
> - filename security is iffy
Ok. That could be improved.
> - the filesystem testing functions in util are named check*
Ok.
> - Test function is too heavy-weight - do the simplest fastest test
> possible. Probably something like:
>
> f, fn = getasecurefilehandleandname(path)
> fn2 = fn + "l"
> link(fn, fn2)
> stat
>
> Even this is pretty expensive.
Near as I can tell, there's no test in my code that is not needed.
But I guess if even the above is too heavyweight, there's not much point
in explaining in detail every case I covered.
More information about the Mercurial-devel
mailing list