Please describe the problem.
see below. expected: entries on failed copies with "success"=false, and not just error messages
$> git annex copy --to=neurosmaug svgtune_0.2.0.orig.tar.gz nonexisting
git-annex: nonexisting not found
copy svgtune_0.2.0.orig.tar.gz (checking neurosmaug...) ok
git-annex: copy: 1 failed
$> git annex copy --to=neurosmaug svgtune_0.2.0.orig.tar.gz nonexisting --json
git-annex: nonexisting not found
{"command":"copy","note":"checking neurosmaug...","success":true,"key":"SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz","file":"svgtune_0.2.0.orig.tar.gz"}
git-annex: copy: 1 failed
$> git annex version
git-annex version: 6.20170220+gitg75a15e1ad-1~ndall+1
I get what you're saying, but there's a layering problem that prevents the JSON display of a higher layer being used by a lower layer that is finding files to operate on.
Trying to copy a file that does not exist is a fundamentally different class of error that an error that occurs when copying a file that does exist. A memory read error resulting in a SIGBUS is a different class of error, as is a git failure due to a corrupted repository. git-annex fails in four entirely different ways in these four cases.
Revisiting this old bug as it's still open. In the mean time, --json-error-messages was added. So at first I wondered if this file not found should be jsonified by that.
Currently, the option adds a error-messages field to the json objects that are output for each file it acts on, so only messages specifically having to do with a specific thing it acts on get json error messages. As I mentioned before, it's not for capturing every possible error message, and really cannot.
In this case, there's at least a filename that coul be said to be being acted on, though of course it's not really acting on it since it DNE. What it could do is output a whole json object just for this file, eg:
It would be rather hard to make that include the "command" field, because currently that is provided to showStart, and this error is happening in the seek stage instead. So the command name would have to be threaded through the seek actions to this error message.
Even if that was done, the json object there is missing the "key" field too.
So that would mean a special case that anything consuming the json could be broken by, if it expects to find a key field and does something with the key.
I suppose maybe it could contain a key that somehow never exists and cannot exist? But this still seems likely to lead to some kind of breakage in some consumer of this. Just for example, maybe someone is consuming the json and building up a list of keys that failed to get copied. Later their program passes the keys to git-annex copy --key or something like that. If a key that will never exist gets emitted, it will gum up that program with something it will never succeed in copying, and it's easy to imagine that leading to undesirable behavior.
So, the benefits seem outweighed by the drawbacks to me, unless there's a very good use case for really wanting the missing file in json output?