diff options
Diffstat (limited to 'doc')
4 files changed, 54 insertions, 0 deletions
diff --git a/doc/bugs/Unable_to_parallel_fsck.mdwn b/doc/bugs/Unable_to_parallel_fsck.mdwn index df7286b20..2d419915d 100644 --- a/doc/bugs/Unable_to_parallel_fsck.mdwn +++ b/doc/bugs/Unable_to_parallel_fsck.mdwn @@ -79,3 +79,5 @@ FAIL 1 Plenty. In fact I've been using it for a long time - I just only recently tried to use -J2 to speed up the fsck'ing :) + +[[!meta title="-J can crash on displaying filenames not supported by current locale"]] 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` +"""]] diff --git a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn index 557b1f13f..470b50722 100644 --- a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn +++ b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn @@ -16,3 +16,5 @@ git-annex version 6.20160114 on Arch Linux. ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) This behaviour is relatively recent. Until some time ago everything worked as expected with the expression above. + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment new file mode 100644 index 000000000..dc4b3dc65 --- /dev/null +++ b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-01-26T18:22:48Z" + content=""" +I think it's worse than that, it lost track of the filename, so +preferred content expressions with include= or exclude= will also do the +wrong thing. + +Going to have to rush out a release fixing this.. +"""]] |