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?

notabug --Joey