On Wed, Nov 13, 2024 at 12:17:00PM +0100, Oswald Buddenhagen via isync-devel wrote: > you forgot to drop the list. but never mind, the log was small.
Yeah, sorry about that. > the local message was un-trashed by something (probably not isync). I use neomutt. It's plausible the issue stems from there. > 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. I tried `mbsync -V --full --old foo:INBOX`, but this didn't fix the problem. > you can manually delete the entries for the ex-trashed messages to cause > them to be re-propagated I then had a look through `.mbsyncstate`, and it does look weird. There are four emails on the local side that are missing from the remote side. I can see their entries in `.mbsyncstate` with a `0` in the first field, as follows. > 0 10292 S > 0 10295 S > 0 10296 S > 0 10300 S I tried deleting one of those lines. mbsync then re-created the entry, and pushed the message to the server, which was the obviously pulled by the other systems. So it worked in the sense that mbsync could track the message again, but it failed since mbsync then spread the duplicated message to all systems. > or you can manually delete the messages themselves. I tried doing this and it seemed to work. The local message was deleted, the entry disappeared from `.mbsyncstate`, and obviously the message was not pushed. I assume this is the way that I can fix my problem? I can grep through all my `.mbsyncstate` files for `0` in the first field, then delete the corresponding messages. I'm not entirely sure what the `0` means; do you think it's a reliable marker that the message is a duplicate for me? I can run some tests anyway and check this. > 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. I assume re-propagation would work as above, and the duplication would spread, so that may not fix my problem at least. In a general sense, probably safer to duplicate than blindly delete though, just in case the tracking arises from other (non-duplicate) causes. Thanks again Oswald. _______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel