handle keys with extensions consistently in all locales
authorJoey Hess <joeyh@joeyh.name>
Thu, 20 Feb 2020 21:18:59 +0000 (17:18 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 20 Feb 2020 21:30:25 +0000 (17:30 -0400)
commit09df58c4ea3f67d5d1fa1d89c4fd4cc0564bac1e
treeb5ef366c1d6059c102c05adcaaa9f6c5a54bd400
parent547e1f29b11532ee27b9737d9250cf7fa92b5a41
handle keys with extensions consistently in all locales

Fix some cases where handling of keys with extensions varied depending on
the locale.

A filename with a unicode extension would before generate a key with an
extension in a unicode locale, but not in LANG=C, because the extension
was not all alphanumeric. Also the the length of the extension could be
counted differently depending on the locale.

In a non-unicode locale, git-annex migrate would see that the extension
was not all alphanumeric and want to "upgrade" it. Now that doesn't happen.

As far as backwards compatability, this does mean that unicode
extensions are counted by the number of bytes, not number of characters.
So, if someone is using unicode extensions, they may find git-annex
stops using them when adding files, because their extensions are too
long. Keys already in their repo with the "too long" extensions will
still work though, so this only prevents adding the same content with
the same extension generating the same key. Documented this by
documenting that annex.maxextensionlength is a number of bytes.

Also, if a filename has an extension that is not valid utf-8 and the
locale is utf-8, the extension will be allowed now, and an old
git-annex, in the same locale would not, and would also want to
"upgrade" that.
Backend/Hash.hs
CHANGELOG
doc/git-annex.mdwn