diff options
author | 2014-05-27 14:16:33 -0400 | |
---|---|---|
committer | 2014-05-27 14:16:33 -0400 | |
commit | 85feb21fb08874b00e96fa172d6e6c7f4cb02660 (patch) | |
tree | 9dd0104be483e8a546231a0eec0f4575dd70f2f9 /doc | |
parent | abafae2d855927568347178a9c678db6348e2b6f (diff) |
Fix encoding of data written to git-annex branch. Avoid truncating unicode characters to 8 bits.
Allow any encoding to be used, as with filenames (but utf8 is the sane
choice). Affects metadata and repository descriptions, and preferred
content expressions.
The question of what's the right encoding for the git-annex branch is a
vexing one. utf-8 would be a nice choice, but this leaves the possibility
of bad data getting into a git-annex branch somehow, and this resulting in
git-annex crashing with encoding errors, which is a failure mode I want to
avoid.
(Also, preferred content expressions can refer to filenames, and filenames
can have any encoding, so limiting to utf-8 would not be ideal.)
The union merge code already took care to not assume any encoding for a
file. Except it assumes that any \n is a literal newline, and not part of
some encoding of a character that happens to contain a newline. (At least
utf-8 avoids using newline for anything except liternal newlines.)
Adapted the git-annex branch code to use this same approach.
Note that there is a potential interop problem with Windows, since
FileSystemEncoding doesn't work there, and instead things are always
decoded as utf-8. If someone uses non-utf8 encoding for data on the
git-annex branch, this can lead to an encoding error on windows. However,
this commit doesn't actually make that any worse, because the union merge
code would similarly fail with an encoding error on windows in that
situation.
This commit was sponsored by Kyle Meyer.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/bugs/forget_corrupts_non-ascii_chars.mdwn | 4 | ||||
-rw-r--r-- | doc/bugs/unicode_tags.mdwn | 3 |
2 files changed, 7 insertions, 0 deletions
diff --git a/doc/bugs/forget_corrupts_non-ascii_chars.mdwn b/doc/bugs/forget_corrupts_non-ascii_chars.mdwn index daee6f63a..f4506c228 100644 --- a/doc/bugs/forget_corrupts_non-ascii_chars.mdwn +++ b/doc/bugs/forget_corrupts_non-ascii_chars.mdwn @@ -72,3 +72,7 @@ backend usage: """]] well that's interesting - the above paste is broken by ikiwiki as well... in the text area where i paste it, "rachel@topcrapn:~/Vidéos/anarcat" shows up as "rachel@topcrapn:~/Vidéos/anarcat" but when i preview, the character gets corrupted. and obviously, the second instance then gets *double* corrupted - wheepee. the original paste has "rachel@topcrapn:~/Vidéos/anarcat". --[[anarcat]] + +> [[fixed|done]]; writes to git-annex branch now preserve the original +> encoding, and I've tested that lots of interesting unicode is preserved +> across a forget run. --[[Joey]] diff --git a/doc/bugs/unicode_tags.mdwn b/doc/bugs/unicode_tags.mdwn index 6ecfad95a..ff3c78666 100644 --- a/doc/bugs/unicode_tags.mdwn +++ b/doc/bugs/unicode_tags.mdwn @@ -44,3 +44,6 @@ OS X 10.9 LC_TIME="en_US.UTF-8" LC_ALL= +> All strings written to the git-annex branch were truncated to 8 bits. +> I've fixed this, and this example works now (of course data written with +> an old git-annex remains truncated). [[done]] --[[Joey]] |