mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

update

Browse source 
Removed some encoding issues that I think are no longer a problem.
This commit is contained in:
Joey Hess 2020-01-06 13:06:10 -04:00
parent 0c904bdf5d
commit a9086df1e7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 2 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

15
doc/todo/windows_support.mdwn
View file

@ -29,19 +29,8 @@ seems unreliable/broken on Windows.
to avoid this, but only ended up with encoding crashes, or worse to avoid this, but only ended up with encoding crashes, or worse
mojibake than this. mojibake than this.
* `md5FilePath` still uses the filesystem encoding, and so may produce the > This may be use to windows actually using utf-16, but git-annex uses
wrong value on Windows. This would impact keys that contain problem characters > utf-8 for filename encoding when on windows.
(probably coming from the filename extension), and might cause
interoperability problems when git-annex generates the hash directories of a
remote, for example a rsync remote.
* `encodeW8` is used in Git.UnionMerge, and while I fixed the other calls to
encodeW8, which all involved ByteStrings reading from git and so can just
treat it as utf-8 on Windows (via `decodeBS`), in the union merge case,
the ByteString has no defined encoding. It may have been written on Unix
and contain keys with invalid unicode in them. On windows, the union
merge code should probably check if it's valid utf-8, and if not,
abort the merge.
* If interoperating with a git-annex repository from a unix system, it's * If interoperating with a git-annex repository from a unix system, it's
possible for a key to contain some invalid utf-8, which means its filename possible for a key to contain some invalid utf-8, which means its filename