followup

doc/todo/Fsck_remote_files_in-flight/comment_2_3baff888fbc3068571cdc9fee73fbe36._comment

@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2021-10-14T15:55:14Z"
+ content="""
+Checksum during transfer is now implemented for as many remotes as it
+reasonably can be, which is almost all of them. But not 100% of all
+remotes in all circumstances. And there's no way to know if a remote
+will support it before doing the transfer.
+
+To avoid changing the API, it occurs to me that retrieveKeyFile could be
+passed `/dev/null`. But any remote that does not support resuming and tries
+to overwrite the existing destination file would fail.
+
+Also some kinds of remotes download to the file in one process or thread
+and while the download is happening, git-annex checksums the file as new
+data appears in it. External special remotes in particular do this.
+That would break with `/dev/null` too.
+
+Putting the temp file on some other medium seems like the only way to
+address this. If there were a config of a directory to use, you could point
+it at a disk rather than the SSD, or even at a ram disk, if you have
+sufficient memory. Unsure if it's worth adding such an option though,
+probably few people would use it. And cloning the repository onto the other
+medium and running the remote fsck from there would have the same result
+without needing an option.
+
+I'm inclined to close this, since I don't think it can be addressed.
+"""]]