diff options
author | Joey Hess <joeyh@joeyh.name> | 2016-01-26 13:49:10 -0400 |
---|---|---|
committer | Joey Hess <joeyh@joeyh.name> | 2016-01-26 13:49:10 -0400 |
commit | 000b0a7e3026cc7b23bdae64f6d535ee0ec37615 (patch) | |
tree | 563064e193cd9325ebe8dde5bbf33ecb43928b8a | |
parent | e4cd36ba9b3af5fd877f75d04aaf428163cd8acd (diff) |
update
-rw-r--r-- | doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment | 39 |
1 files changed, 39 insertions, 0 deletions
diff --git a/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment b/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment new file mode 100644 index 000000000..104d6b3c4 --- /dev/null +++ b/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment @@ -0,0 +1,39 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-01-26T16:21:56Z" + content=""" +I can reproduce this with LANG=C. + +The cause seems to be that concurrent-output uses Text internally, and +Strings encoded using the filesystem encoding fail to round-trip through +Text. + +I tried changing concurrent-output from using `T.hPutStr stdout t` to +`hPutStr stdout (T.unpack t)` but that doesn't help; by the time the String +comes back out it's lost the filesystem encoding and so contains invalid +characters. + +Seems that the only way to fix this would be to change concurrent-output +not to use Text. However, it can't use ByteString because it needs to +operate on individual unicode characters when updating a region. +Which leaves only String, which I fear would slow +concurrent-output down quite significantly. + +(It might be possible to use ByteString for most of it, and fall back to +String only when calculating the display update and so avoid most of the +permformance impact. I have an incomplete conversion headed in that +direction in the use-bytestring branch in concurrent-output git repo. After +spending 2 hours on it, it's nowhere near done.) + +Since git-annex remains usable without -J, and since this only affects +systems that don't have a unicode locale configured and yet are using +unicode filenames (or systems that do use a unicode locale and have +filenames that are not valid utf-8), I'm kind of inclined not to massively +rework and likely slow down concurrent-output just to handle this case. +But I don't like it. + +Workaround: Compile git-annex with -f-ConcurrentOutput and the problem +will be avoided, although then you won't get progress displays when doing a +`git-annex get -Jn` +"""]] |