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

Reply via email to