status update
This commit is contained in:
parent
8613770b06
commit
f8463ad52f
1 changed files with 19 additions and 6 deletions
|
@ -5,11 +5,24 @@
|
|||
content="""
|
||||
The concurrency problem is fixed now.
|
||||
|
||||
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
|
||||
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.
|
||||
Directory and webdav now also do incremental hashing.
|
||||
|
||||
The ones that do are: external, adb, gcrypt, hook, rsync, directory
|
||||
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, 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. The new `fileRetriever\`` can be used instead to fix these,
|
||||
but will take some more work.
|
||||
|
||||
Also, retrieval from export/import special remotes does not do incremental
|
||||
hashing.
|
||||
"""]]
|
||||
|
|
Loading…
Reference in a new issue