Merge branch 'master' of ssh://git-annex.branchable.com

doc/bugs/content_retrieval_from_borg_remote_fails_over_ssh/comment_2_d88ab318b6edc3eea47f8360f31cd91f._comment

@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="alt"
+ subject="comment 2"
+ date="2021-07-16T12:37:47Z"
+ content="""
+Thank you for the amazingly quick fix!
+"""]]

doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_2_82a5d9005dca476916e4b5df671e3111._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="guardcat"
+ avatar="http://cdn.libravatar.org/avatar/60a9f9f0159e3a732d448f0fd5642d41"
+ subject="Fixing problem"
+ date="2021-07-16T06:21:23Z"
+ content="""
+Thanks for you answer! 
+Sorry for choosing the wrong way to report the rpoblem. It happend because I didn't think it's the program's bug I thought it's my mistake.
+My WSL repo works on FAT32 so it's crippled. The version it the exactly what the git annex says me by ```git annex version``` on WSL. May be Ubuntu developers repacked it?
+
+# How I got into
+1. On the WSL system I mounted NTFS usb-stick.
+2. I created a folder on the usb stick and run ```git init``` and ```git annex init``` in it.
+3. I gone to my HDD repo and done ```git remote add usb /way/to/usb/folder```.
+4. I set ```archive``` group for the usb stick.
+5. I done ```git annex sync --content``` that copied all needed files to the usb stick. 
+6. When I started sync at home I noticed that not all files are on the usb stick. 
+
+# As I seem to have fixed it
+I use my distributive's version of git annex, so I wil get the new version much later.
+I done some steps to fix the problem. Were I right?
+I started ```git annex fix``` in my bare repo, and this command found that approximately a half of files aren't present though they ought to be there according to log. Log was fixed in three hours and then I synced repos. But my WSL repo is behind a NAT so I will sync it in several days and I a little afraid of some problems with it.
+
+If you can give me some pieces of advice to avoid further porblems in my situation I woud be happy.
+"""]]

doc/forum/Can__39__t_get_some_files_from_bare_repo/comment_3_430c7854e33ff3e821ebd00b436dbf45._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="guardcat"
+ avatar="http://cdn.libravatar.org/avatar/60a9f9f0159e3a732d448f0fd5642d41"
+ subject="appendix"
+ date="2021-07-16T06:34:53Z"
+ content="""
+And I forgot to add: my home repo is on ext4, so it isn't cripled. And my work repo and the repo on my usb stick are marked as a crippled filesystem both.
+"""]]

doc/todo/Hardlink_keys_with_same_hash_but_differrent_ext/comment_7_fed82ecac17e6ed86eb18232d4b5ae6a._comment

@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="Atemu"
+ avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
+ subject="comment 7"
+ date="2021-07-16T11:21:43Z"
+ content="""
+Ah I see. The whole tree would have to be scanned for SHA256H references of a certain SHA256 key on `get` and tree-modifying commands like `checkout`.
+
+With the existing backends that doesn't need to happen since the key existing in the local repo implies that it is reachable via the symlinks in the checkout.
+
+Trickier than I had anticipated, thank you for your insights!
+
+Maybe the extension aliases of a key could be recorded and simply applied in every repo a key exists in. This might require another lookup on get (though it could perhaps be done in the same lookup) but, since it'd require a lookup of a key anyways under SHA256E because they're entirely separate, we wouldn't lose on performance either.  
+The only problem would be propagating new aliases on `sync`...
+"""]]