fsck: Support --json.

One use case is to get a list of files that fsck fails on, in order to eg,
drop them from a remote.

This commit was sponsored by Nick Daly on Patreon.

CHANGELOG

@@ -1,6 +1,7 @@
 git-annex (6.20170521) UNRELEASED; urgency=medium
 
   * Fix build with QuickCheck 2.10.
+  * fsck: Support --json.
 
  -- Joey Hess <id@joeyh.name>  Sat, 17 Jun 2017 13:02:24 -0400
 

Command/Fsck.hs

@@ -42,7 +42,7 @@ import Data.Time.Clock.POSIX
 import System.Posix.Types (EpochTime)
 
 cmd :: Command
-cmd = withGlobalOptions (jobsOption : annexedMatchingOptions) $
+cmd = withGlobalOptions (jobsOption : jsonOption : annexedMatchingOptions) $
 	command "fsck" SectionMaintenance
 		"find and fix problems"
 		paramPaths (seek <$$> optParser)

doc/bugs/Delete_data__47__update_location_log_when_a_special_remote_fails_to_fsck/comment_1_203ebe6fa1bb8d3c6e7c0b948fc7dd6b._comment

@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-06-26T17:14:56Z"
+ content="""
+`fsck --from remote` is supposed to update the location log when it
+determines that the remote does not contain the file.
+
+But in your case, the decryption failure appears to fsck as a transfer
+failure, which as you note can be transient. So it doesn't update the
+location log.
+
+It seems that what's needed is different errors to be returned when
+download fails, vs when download succeeds but decryption/verification fails.
+Then fsck could mark the file as not being present in the remote
+in the latter case.
+
+Although, that would leave the presumably corrupted encrypted data in the
+remote. (Unless fsck also tried to delete it.)
+
+Also, decryption can fail for other reasons, eg missing gpg keys,
+and in such a case, it would be bad for fsck to decide that the remote
+didn't contain any content! (And super bad for it to delete it from the
+remote!!)
+
+So hmm, I'm not sure about that idea.
+
+Your idea of getting a list of files that fsck failed to download
+is certianly useful. Perhaps a good way would be to make `git annex fsck
+--from remote --json` work, then the json output could be parsed to get a list of
+files, and you could use `git annex drop --from remote` to remove the bad
+data. That was the easiest possible thing, so I've made that change.
+"""]]

doc/git-annex-fsck.mdwn

@@ -93,6 +93,11 @@ With parameters, only the specified files are checked.
 
   Runs multiple fsck jobs in parallel. For example: `-J4`
 
+* `--json`
+
+  Enable JSON output. This is intended to be parsed by programs that use
+  git-annex. Each line of output is a JSON object.
+
 # OPTIONS
 
 # SEE ALSO