[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2025-09-22T22:53:53Z"
 content="""
I have confirmed this bug.

It seems specific to deleting the file from the special remote.
If the file is instead modified, the modification gets imported.

I modified importChanges to always use fullimport, rather than diffimport,
and that avoids the bug. (It also causes the next import from the special
remote to notice *all* the previously deleted files, so it recovers from
the bug as well.)

I've confirmed that in this case, the diff that is generated by
importChanges does not contain the deleted file.

In fact, in this case, importChanges diffs prevcidtree to currcidtree,
but somehow, both trees have the same sha1.

Given that doing an import before the change avoids the problem,
I think what must be happening is that the import is calling
recordContentIdentifierTree with the tree containing the file. So the 
later diff then sees that it is deleted. In contrast, when only exporting,
it does not call recordContentIdentifierTree. And so the previously
recorded tree is used. Which in this case is the same tree as the new
tree, since the breifly added file has been removed again.

So, to fix this while keeping the diffimport optimisation,
export should also call recordContentIdentifierTree. 
Although that may be easier said than done.
Alternatively, export could invalidate the old content identifier tree.
Which would make the subsequent import do a fullimport. That would at least
let the diffimport optimisation be used when doing repeated imports
without any exports.
"""]]
