Mmm. I doubt the added complexity warrants it, but we could
- keep an index of full file hash => FileInfo
- when the scanner detects a new file, it checks this index, and
- stat each file with the same hash, in the same folder
- if it doesn't exist, commit the new entry and the delete together.
But this is still no guarantee. In the index sender we might put the message boundary between the add and the delete. For example, if we've already queued enough entries that adding the delete as well to the message would exceed the desired message size, or if the file itself is large enough to warrant it's own message.
To do it "atomically" we'd need to add a field to the FileInfo itself indicating that it's a rename. That will probably have vast negative consequences and cause weird situations by itself...
I think this is just a caveat to be aware of - renames are best effort.
Changing this constant to a few seconds instead of zero would probably bring up the hitrate a fair amount though.