[PATCH 0 of 2] fncache and long filenames and '.' as 8th character

Mads Kiilerich mads at kiilerich.com
Sat Apr 21 10:55:46 CDT 2012


http://mercurial.selenic.com/bts/msg8154 discussed windows safety of the then
new fncache encoding of long filenames and said:

> We've got two choices:
> 
> a) spin the repository layout ("fncache2"?)
> b) quickly fix the bug and hope that no one is affected

fncache was introduced in 1.1 and b) was committed in e54cf540c6ca and released
in 1.1.1.

> We've done (b) before, when we added escaping for directory names ending in .d
> or .i. I think a total of one user was affected. This may be a similar situation.

This time I am the user that was affected. A server had been running 1.1 for
years - and when I upgraded it the repos broke in mysterious ways.

> To hit this bug, you need a pathname longer than 100 characters and it needs to
> have a space in the 8th character of some directory name. Mildly improbably.

A '.' as 8th character is less improbable and not so much bad practice ... for
example if a version number for some reason has to be encoded in the path name.

> To have a compatibility problem with some Linux user after applying this patch,
> you have to create a repo with 1.1.1 with an affected file, then try to access
> the repo on the same disk (NFS, external drive, etc.) using 1.1 on Linux.
> 
> The reverse won't be an issue. If you create a 1.1 repo with an affected file on
> Linux, Windows will be upset anyway by the extra space.

The problem is also be seen on linux when a repo is created with 1.1 and
uses for example .hg/store/dh/1234567./ on disk. When upgrading to 1.1.1 or
later it will use .hg/store/dh/1234567_/ and thus see a repository corruption.

A hackish way to fix the file location on disk (and make it incompatible with
1.1) is something like:

find .hg/store/dh -name '*.'|while read f; do f_=`echo "$f"|sed 's,\.$,_,g'`; mv "$f" "$f_"; done

Hg would however 'helpfully' have removed the corresponding entries from
fncache while the revlog was missing, so they have to be added again. The
following patch mitigates that pruning and let verify clean up after itself
when it notice that the situation isn't so bad anyway.

/Mads


More information about the Mercurial-devel mailing list