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 2021-07-13 12:47:56 -04:00
parent 7b615c6bc4
commit ce6a288412
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/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment Normal file
View file

@ -0,0 +1,33 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2021-07-13T16:20:10Z"
content="""
There is some precident for this; `git annex migrate`
hard links the annex objects for the old and new key.
But hard links are also used for unlocked files with annex.thin,
and when the object file is hard linked to somewhere already,
it is unable to hard link it to the unlocked file location, and so
annex.thin doesn't work.
It would perhaps make sense for such a hard link to be broken when
populating an unlocked file when annex.thin is enabled. Ie, replace
the object file with a copy of itself. Which can then be hard linked to the
unlocked file. That would also improve the situation when it's been
migrated.
This feature would also need a way to find all the other equivilant keys
that are in use, which would have to be done whenever an object file gets
populated. So it would need to be very fast, otherwise it would slow down
eg `git annex get`. While the keys database does have the necessary
information in it (finally), it would need to select keys matching a
pattern, which I doubt would be an optmised query, even if the index
in the database can be used.
(See <https://sqlite.org/optoverview.html#like_opt>)
Even if the query were optimised, it could turn out to be a significant
speed hit.
And I have a feeling that most people bothered by this duplication
would just do better to migrate away from SHA256E to SHA256..
"""]]