doc/bugs/10.20220525_cannot_probe_for_untrusted_remote_key.mdwn

@@ -0,0 +1,25 @@
+### Please describe the problem.
+10.20220525 forcefully untrusts `exporttree=yes`, causing `fsck` to unconditionally fail when probing for a key that only exists on such a remote.
+
+The full story is at https://github.com/datalad/datalad-next/issues/72
+
+The summary is that an application needs to know whether a particular key is on such a remote, and it can only be on that remote (there is no other). Because the availability info from `whereis` cannot be trusted (same rational as the one causing the change in git-annex implementation) it uses `annex fsck --fast --key -f ...` which now fails.
+
+Parsing the JSON output of the failing `fsck` call seems to be the only way left to accomplish this goal.
+
+```
+% git -C myclone/.git/dl-repoannex/origin/repoannex -c diff.ignoreSubmodules=none annex fsck -f origin --fast --key XDLRA--refs -c annex.dotfiles=true --json
+  Only these untrusted locations may have copies of XDLRA--refs
+        d8735795-663e-4702-8f7e-8c684264a9df -- [origin]
+  Back it up to trusted locations with git-annex copy.
+{"dead":[],"command":"fsck","note":"(Avoid this check by running: git annex dead --key )","success":false,"input":[],"untrusted":[{"here":false,"uuid":"d8735795-663e-4702-8f7e-8c684264a9df","description":"[origin]"}],"key":"XDLRA--refs","error-messages":[],"file":null}
+fsck: 1 failed
+```
+
+That however, is substantially more complex than looking at the exit code -- given that the entire call is about a single key.
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+99.9% are just splendid. Wondering here whether this particular consequence of the change was intentional and avoidable?
+
+