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

comment

Browse source
This commit is contained in:
Joey Hess 2025-06-03 15:19:37 -04:00
parent 05b4a9e230
commit 167cf2cc52
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 33 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

33
doc/bugs/compute_remote_fails_for_unicode_filenames/comment_4_c39de00401ad7f96fde93305e232139a._comment Normal file
View file

@ -0,0 +1,33 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2025-06-03T19:05:35Z"
content="""
Nice work investigating this. I would not have guessed a kernel bug might
be involved. But I am not convinced one is, either.
I agree with your analysis of your strace. The filename is getting into
git-annex ok. Then it runs the compute program with the mangled filename.
I don't see how a kernel bug would cause git-annex to mangle the filename
though. As far as `git-annex addcomputed` is concerned, the filename is
just a parameter to use as input to the computation. Such parameters are
not limited to filenames actually. And so they pass through `git-annex
addcomputed` without being exposed to any kernel syscall that might do
something wrong on a buggy kernel.
Unless, that is, the haskell `process` library, or indeed the kernel
itself, does something with parameters passed to the compute program.
(This strace does rule out my theories around `hGetLineUntilExitOrEOF`.)
----
What are the versions of git-annex in the VM where it worked vs
where it didn't?
And, if you can possibly download and unpack the linuxstandalone tarball,
and use that to run git-annex in the bad VM, that would be a useful check
that the problem does not somehow involve the homebrew build.
<https://git-annex.branchable.com/install/Linux_standalone/>
"""]]