On Thu, Jul 29, 2021 at 09:33:35PM +0900, Norbert Preining wrote:
don't worry about the x-tuids - they are temporary state of mbsync which matters only when using a server without UIDPLUS support or if the transfer is interrupted. in principle they could be removed after successful sync, except that messages are immutable once stored (except for flags).- on the server there is still only one file - on the client/near side there are **two** copies of the trashed email which differ only in the X-TUID header. **Both** have a X-TUID header, but two different ones.I also confirmed that the email on the server in the Trash does **NOT** contain a X-TUID header. Next, looking at the time stamps, I see Server/Far: -rw------- 1 norbert norbert 32535 Jul 29 10:02 '1627560842.M568266P27776.hz,S=32535,W=33284:2,S' no X-TUID header Client/Near: -rw------- 1 norbert norbert 32556 Jul 29 10:03 1627560854.80257_1.bulldog:2,ST -rw------- 1 norbert norbert 32556 Jul 29 21:14 '1627560855.80257_2.bulldog,U=415506673:2,S' both contain two different X-TUID headers
the first client-side message has no U= infix, which suggests that it's not from mbsync - or that something messed up the file name afterwards, which might explain ... something ... i guess. but both files are apparently from the same process. very mysterious, indeed.
are you by any chance trying to use both the synced trash folder and mbsync's built-in trash function? if so, don't.
otherwise, to get to the bottom of it, run mbsync with -D, starting with a clean slate, and continuing until the state stabilizes. make a note of any other processes started in between (make sure nothing happens in the background). also, your config file would be relevant. post or mail me in private.
_______________________________________________ isync-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/isync-devel
