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

comments

Browse source
This commit is contained in:
Joey Hess 2022-09-16 13:40:27 -04:00
parent 8307e0f63f
commit 4a1030d51d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 55 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_1_b9491e9cb432ca3b8bdb08a00c89b346._comment Normal file
View file

@ -0,0 +1,37 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-09-16T17:10:24Z"
content="""
"file content has changed" is a message from the directory special remote
when it sees that a file in the directory has a different mtime,size,inode
tuple (content identifier) than the one that was recorded when importing
the tree.
Maybe that has something to do with the duplicate files, since they would
have different inodes. Except, it does try to support that; it can keep
track of multiple content identifiers for a key, and when there are
duplicate files, that works in my testing.
I notice that, if I have a directory special remote that was initially
set up with ignoreinodes=no, and I've imported a tree that way from it,
I can cause what looks like this problem:
joey@darkstar:~/tmp/bench/x>git-annex enableremote t directory=../x ignoreinodes=yes
enableremote t ok
(recording state in git...)
joey@darkstar:~/tmp/bench/x>git-annex get 3 --from t
get 3 (from t...)
file content has changed
Which seems like a bug that it allows changing it, but I think that the idea was
that, after changing ignoreinores, the user would re-run git-annex import,
which would re-import all the files since the content identifier has
changed. Still, I think that
[[!commit 3e2f1f73cbc5fc10475745b3c3133267bd1850a7]] didn't consider that
it could cause a get to fail.
I know you have recently upgraded from a version that defaulted
to ignoring inodes. Maybe you only need to re-run `git-annex import` from the
directory remote to fix the problem?
"""]]

18
doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_2_cf9ce09377da2eae63ff41d07cb222d7._comment Normal file
View file

@ -0,0 +1,18 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2022-09-16T17:32:29Z"
content="""
If I was on the wrong track with my first comment, it would be helpful
to take a look at the content identifier that is recorded for
the key, by running:
git show git-annex:$(git-annex examinekey SHA256E-s55936559--0d418e4bb62cfc7ef5b053f8b622dd72794781a49931abc41bb9499acaf51b09.mp4 --format='${hashdirlower}${key}.log.cid')
The part after the UUID in the output is the content identifier(s). If more
than one, they are separated by colons. The format of a content identifier
is "inode size mtime", and the inode will be 0 if it was generated with
ignoreinodes=yes. So you could then compare the content identifiers
with the stat of the files in the directory special remote and see if
something has actually changed.
"""]]