status update
authorJoey Hess <joeyh@joeyh.name>
Mon, 16 Aug 2021 21:29:39 +0000 (17:29 -0400)
committerJoey Hess <joeyh@joeyh.name>
Mon, 16 Aug 2021 21:29:39 +0000 (17:29 -0400)
doc/todo/OPT__58_____34__bundle__34___get_+_check___40__of_checksum__41___in_a_single_operation/comment_16_fbbcf1d8b35078274cfe322cea6de21c._comment

index fe50195cf3c00c926d808e1f2f7ad20739f9c2bf..d24203b2b10c02d236008d420ab08649126bac3d 100644 (file)
@@ -5,11 +5,24 @@
  content="""
 The concurrency problem is fixed now.
 
+Directory and webdav now also do incremental hashing.
+
+There seems to have been a reversion in annex.verify handling; 
+I'm seeing directory do incremental hashing even when annex.verify is
+false. Noticed while benchmarking it to see how much incremental hashing
+sped it up. Seems that in Remote.Helper.Special, it uses
+RemoteVerify baser, but when shouldVerify checks that value, it
+sees that Types.Remote.isExportSupported is true. Despite the remote
+not actually being an export remote. Because adjustExportImport gets
+run after that point, I think..
+
 As well as the web special remote, these do not do incremental hashing
-still: gitlfs, webdav, S3. Problem is, these open the file
-for write. This prevents tailVerify re-opening it for read, because the
+still: gitlfs, S3. Problem is, these open the file
+for write. That prevents tailVerify re-opening it for read, because the
 haskell RTS actually does not allowing opening a file for read that it has
-open for write. This problem has already been fixed for directory.
+open for write. The new `fileRetriever\`` can be used instead to fix these,
+but will take some more work.
 
-The ones that do are: external, adb, gcrypt, hook, rsync, directory
+Also, retrieval from export/import special remotes does not do incremental
+hashing.
 """]]