From ce6a28841273aebed9642eda997e54e9339c7950 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 13 Jul 2021 12:47:56 -0400 Subject: [PATCH] comment --- ..._ad76bcde941d6f1719260179a7bd27ba._comment | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment diff --git a/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment new file mode 100644 index 0000000000..48a74a8510 --- /dev/null +++ b/doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_2_ad76bcde941d6f1719260179a7bd27ba._comment @@ -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 ) +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.. +"""]]