more thoughts
This commit is contained in:
parent
cd20dc4158
commit
7dcc815c29
1 changed files with 6 additions and 3 deletions
|
@ -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:
|
||||
|
|
Loading…
Reference in a new issue