comment
This commit is contained in:
parent
223f03e84c
commit
612d2a8056
1 changed files with 31 additions and 0 deletions
|
@ -0,0 +1,31 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 5"""
|
||||
date="2022-09-20T16:23:07Z"
|
||||
content="""
|
||||
The two files have the same two inodes that are recorded in the git-annex
|
||||
branch. The size and mtime also seem to match. Interesting,
|
||||
it must be another problem than the one I fixed.
|
||||
|
||||
I wonder if it's expecting the first file to have the second one's inode,
|
||||
or vice-versa?
|
||||
|
||||
I don't know how that would have happened to you, but I was able to force
|
||||
it to happen, by importing a tree from a directory remote that had 2
|
||||
duplicate files. Then I swapped the names of the 2 files in the directory.
|
||||
This causes git-annex get to fail with the same error message.
|
||||
|
||||
That must be a bug itself, because re-importing from the special remote
|
||||
generates the same tree (of course) and so get continues failing, there is
|
||||
no recovery possible except deleting or touching the files.
|
||||
|
||||
Aha: Another indication that handling of duplicate imported files is broken
|
||||
is to import two files, and then delete the first of them. This also causes
|
||||
git-annex get to fail, but now it always fails with "no such file or
|
||||
directory". It is only trying to get the first file, it does not try the
|
||||
second. Re-importing from the special remote teaches it about the deleted
|
||||
file, and that leads back to the "file content has changed" problem because
|
||||
it seems to be looking for the deleted file's inode. So that's one way you
|
||||
could have gotten into this situation without the unlikely swapping of two
|
||||
duplicate files.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue