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

Added a comment: Cause cannot (only) be a v7->v8 upgrade

Browse source
This commit is contained in:
mih 2021-07-29 05:40:36 +00:00 committed by admin
parent a306560374
commit 1e5c60132a
1 changed files with 35 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
doc/bugs/__34__failed_to_send_content_to_remote__34__/comment_22_4b6cf4221ff9d4f106d595f2897ea85f._comment Normal file
View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="mih"
avatar="http://cdn.libravatar.org/avatar/f881df265a423e4f24eff27c623148fd"
subject="Cause cannot (only) be a v7->v8 upgrade"
date="2021-07-29T05:40:36Z"
content="""
I posted an update to https://github.com/datalad/datalad/issues/5613#issuecomment-888813877 Below is an edited version:
The repository this issue is referring to is indeed old (started in 2015). So an upgrade from 7 (or earlier) is a potential cause. It is currently a version 8 repo.
Moreover, I can still replicate the exact same issue with `git-annex version: 8.20210310`. I have not attempted to use the newest git-annex to preserve the state of this repo.
I can confirm, however, that this issue is unrelated to the special datalad special remote implementation. I created a plain new remote on the local filesystem, and I can see the same behavior when attempting to copy the key to it:
```
% git remote -v
...
tmp /tmp/mytest (fetch)
tmp /tmp/mytest (push)
% git annex copy --to tmp --key MD5E-s190--e6e1f4d3923cfd861e23f0f4cb20fa03.mat
copy MD5E-s190--e6e1f4d3923cfd861e23f0f4cb20fa03.mat (to tmp...)
failed to send content to remote
failed to send content to remote
failed
git-annex: copy: 1 failed
```
That being said, the cause cannot (only) be a v7 to v8 upgrade. The repository concerning https://github.com/datalad/datalad/issues/5750 was created in April 2021 (v8 from the very start), and there are more recent examples too.
In both cases a `git annex fsck` was attempted in the repository from which a key was to be transferred from. In both cases that did not fix the issue. As far as I understand the fix made in 8.20210715-g3b5a3e168 forces a file checksuming before transfer. This is an expensive change, and the `fsck` should have already performed the same checksuming. Should `fsck` not also be able to update the respective key property caches?
"""]]