[Bug 3958] New: Regression in fncache long path handling causing repository corruption.

[mercurial-bugs at selenic.com]

http://bz.selenic.com/show_bug.cgi?id=3958

          Priority: urgent
            Bug ID: 3958
                CC: mercurial-devel at selenic.com
          Assignee: bugzilla at selenic.com
           Summary: Regression in fncache long path handling causing
                    repository corruption.
          Severity: bug
    Classification: Unclassified
                OS: All
          Reporter: platings at ccdc.cam.ac.uk
          Hardware: All
            Status: UNCONFIRMED
           Version: 2.5
         Component: Mercurial
           Product: Mercurial

In Mercurial 2.4.2 a file with the path such as:
12345678901234567890/1234567890/1234567890/1234567890/1234567890/1234567890/1234567890/1/2/3/4/5/6/7/8/9/0/1234567890

is added to the Mercurial store at:
.hg/store/dh/12345678/12345678/12345678/12345678/12345678/12345678/12345678/1/2/3/123456d09851d3f8073abca8cd33aa631f7911219c3fce.i

Mercurial 2.5 (and later versions) expect such a path to exist at:
.hg/store/dh/12345678/12345678/12345678/12345678/12345678/12345678/12345678/1/2/12345678d09851d3f8073abca8cd33aa631f7911219c3fce.i

Therefore after upgrading to Mercurial 2.5 or later, hg operations such as
merge can fail and hg verify reports errors beginning with "missing revlog!".

Worse, even after downgrading Mercurial to 2.4.2 the same operations fail
because merely running hg verify with 2.5 or later corrupts .hg/store/fncache.

I've identified the offending changeset as
http://selenic.com/hg/rev/8c019d2fd7c03f073f7b879ccb87f3e2891bce8a
It seems that the C hashencode function behaves slightly differently to the
Python _hashencode function.

I'll send a regression test patch mercurial-devel at selenic.com

-- 
You are receiving this mail because:
You are on the CC list for the bug.