mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

avoid uncessary call to inAnnex

Browse source 
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:
Joey Hess 2021-10-01 12:02:35 -04:00
parent 17a31f8e1b
commit b9a1cc512d
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 33 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__.mdwn
View file

@ -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]]

17
doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_11_d485bbc1c0f2fceaaa2e4142dccdc1f7._comment Normal file
View file

@ -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.
"""]]