more thoughts

This commit is contained in:
Joey Hess 2019-06-04 14:38:55 -04:00
parent cd20dc4158
commit 7dcc815c29
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -28,13 +28,16 @@ process.
INSERT INTO associated VALUES(4,'SHA256E-s30--7d51d2454391a40e952bea478e45d64cf0d606e1e8c0652bb815a22e0e23419a,'foo.ü');
INSERT INTO associated VALUES(5,'SHA256E-s30--7d51d2454391a40e952bea478e45d64cf0d606e1e8c0652bb815a22e0e23419a','"foo.\56515\56508"');
And it seems likely that a query by filename would fail if the filename
was in the database but with a different encoding.
* IKey could fail to round-trip as well, when a Key contains something
(eg, a filename extension) that is not valid in the current locale,
for similar reasons to SFilePath. Using BLOB would be better.
See [[!commit cf260d9a159050e2a7e70394fdd8db289c805ec3]] for how the
encoding problem was fixed for SFilePath. I reproduced a similar problem
by making a file `foo.ü` and running `git add` on it in a unicode
See [[!commit cf260d9a159050e2a7e70394fdd8db289c805ec3]] for details
about the encoding problem for SFilePath. I reproduced a similar problem
for IKey by making a file `foo.ü` and running `git add` on it in a unicode
locale. Then with LANG=C, `git annex drop --force foo.ü` thinks
it drops the content, but in fact the work tree file is left containing
the dropped content. The database then contained: