analysis

doc/bugs/__96__sync_-C__96___takes_longer_to_get_file_than___96__get__96__/comment_10_43f5ed4a319fcf63387395f32a345852._comment

@@ -0,0 +1,38 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 10"""
+ date="2021-10-01T14:57:11Z"
+ content="""
+The second hash is done by isUnmodifiedLowLevel, and
+is indeed done because the inode cache does not verify.
+
+The inode cache does not verify because for some reason,
+it does not have any inode cached for the object file
+when that is called.
+
+The reason this only happens in sync and not get is that sync also sends
+files it received to other remotes, and to do that it needs to check if
+their content is present. Which is normally inexpensive, so not a problem.
+
+It so happens that sync calls inAnnex even when
+there are no other remotes to send the content to. Which is unncessary, and
+avoiding that could be used to fix this problem. But there would still be a
+problem if there were some other remote that the content ought to be sent to,
+if it still called inAnnex in that case. Maybe it's possible to avoid it calling
+inAnnex at all though, since it knows when it's gotten the content.
+
+The inode cache gets written to the database before sync calls
+inAnnex. And queued writes get flushed to the database before reading
+from it. I've confirmed all this is happening.
+So why does getting the inode cache from the db not see the previously
+written data?
+
+I suspect this is where NTFS enters the picture. Perhaps
+something about it is causing changes to the sqlite database to not
+be visible immediately to a reader. Might involve whatever locking
+sqlite is or is not able to do on NTFS, or something like that.
+
+(Interestingly, at the end of the sync, the smudge clean filter
+gets called, and it is able to read the inode cache from the db
+at that point. So another process run just a bit later can see the data.)
+"""]]