On Wed, Nov 13, 2024 at 08:56:54PM +1100, sourcefo...@plast.id.au wrote:
I've attached the log.
you forgot to drop the list. but never mind, the log was small.
I'm not sure if helpful, but one of the messages that exists on my local system
and not the remote system is named
1730960491.400661_1.hostname,U=12352:2,S
the log already tells me the interesting part of that:
uid=12352 flags=S size=0 tuid=?
anyway, let's get on with a specific affected message:
reading sync state /home/username/.mail/foo/Inbox/.mbsyncstate ...
...
uid val 1619652321/1621387924, max uid 18916/12373, max expired 0
...
entry (0,12350,ST,)
...
N: [ 6] Callback enter load_box, sts=0, total=147, recent=0
...
uid=12350 flags=S size=0 tuid=?
...
synchronizing old entries
...
pair (0,12350)
no far side
...
this is a clearly bogus state, and i can only speculate what happened:
isync saw the deletion on the server and pulled it. but rather than
being subsequently expunged externally as the configuration kinda
promises, the local message was un-trashed by something (probably not
isync). but as far as isync is concerned, it's _done_ with that message.
you can try playing with the Sync option, in particular adding Old
("Sync Full Old" should work, iirc), but i think this will merely add
"ignoring orphaned message" messages to the debug log.
you can manually delete the entries for the ex-trashed messages to cause
them to be re-propagated, or you can manually delete the messages
themselves.
isync could automatically re-propagate messages that are un-trashed, but
relying on such behavior does not seem like a sane workflow to me.
i suppose it should warn about flag changes in orphaned messages.
_______________________________________________
isync-devel mailing list
isync-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/isync-devel
