avoid uncessary call to inAnnex
sync --content: Avoid a redundant checksum of a file that was incrementally verified, when used on NTFS and perhaps other filesystems. When sync has just gotten the content, it does not need to check inAnnex a second time. On NTFS, for some reason the write of the inode cache after it gets the content is not immediately able to be read, and with an empty/non-matching inode cache due to that stale data, inAnnex falls back to hashing the whole object to determine if it's present. Sponsored-by: Brock Spratlen on Patreon
This commit is contained in:
parent
17a31f8e1b
commit
b9a1cc512d
4 changed files with 33 additions and 10 deletions
|
@ -724,3 +724,5 @@ from 159 to 296985).
|
|||
Git Annex is great. It works quite nicely with my multi-gigabyte backup files (largest around 180GB) via the BLAKE2B160E backend :)
|
||||
|
||||
[[!meta title="windows: sync -C takes longer than get, apparently extra checksum"]]
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,17 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""comment 11"""
|
||||
date="2021-10-01T15:57:12Z"
|
||||
content="""
|
||||
Fixed by avoiding sync calling inAnnex when it knows it has the content,
|
||||
because it just got it.
|
||||
|
||||
This does leave open the possibility that there are similar situations
|
||||
elsewhere, that lead to either extra work like this, or to incorrect
|
||||
behavior. Since sqlite write followed by a read is generally something
|
||||
git-annex is careful of, and also since it is generally careful to have
|
||||
reasonable behavior is sqlite somehow loses data, I'm not too worried about
|
||||
incorrect behavior. I feel comfortable closing this bug with just this fix,
|
||||
despite not getting to the bottom of the issue of why sqlite writes are
|
||||
not immediately able to be read back on NTFS.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue