On Wed, Dec 1, 2021 at 6:12 AM Oswald Buddenhagen <oswald.buddenha...@gmx.de> wrote:
> On Tue, Nov 30, 2021 at 06:44:14PM -0500, Peng Bai via isync-devel wrote: > >if a message was previously synced > >and then marked `\Deleted` and expunged, this trick will not re-sync it > but > >instead gives a warning: > >~~~ > >pair (4749,2358) > >Notice: conflicting changes in (4749,2358) > > > you get this notice when you change the message on *both* sides, in > different ways. i suppose you might have marked the message as deleted > on both sides and expunged it only on the near side. > Yes, and to clarify, what happened was: 1) messages were pulled from far -> near; 2) some of these messages were marked `\Deleted` on the far side; 3) the `\Deleted` flags were pulled from far -> near and expunged (because I have `Sync Pull` and `Expunge Near`); 4) the `\Deleted` messages were removed from the far side; warnings appeared at this point (thanks for the patch!); 5) I hacked the state file to change `MaxPulledUid 0` in the hope that mbsync will re-sync the now expunged messages, but this didn't happen -- is there a way to achieve this at present? > > arguably, it's a bit stupid to print the notice when executing the sync > operation would actually result in the same change. you can try the > attached patch if you feel like it. > > > not pushing delete > > > that means that you explicitly omitted deletion pushing from the sync > operations. > > I kind of understand this because I was doing `Sync Pull` so there should be no near->far propagation of anything. >My use case is that I want to review messages > >on the far side that are marked `\Deleted` (by some automatic process) and > >may un-`\Deleted` some of them, but I do want to delete and expunge > >messages on the near side for those that are completely deleted on the far > >side. I'm having some difficulty in devising a scheme to make this work. > > > you could first do a pull with expunge, then (for the time being) hack > the state file (a simple sed script should do), and then do a pull > without expunge. then you'd do the manual review, and finally push > (flags and deletions). > I'm a bit confused how this will work. Please see the description of my workflow above. My setup may be a bit weird as I'm working with mails on the far side and the near side is a backup that only mbsync touches. Information only propagates from far -> near. For reference, I paste my setup below. ~~~ Channel Far2Near Far :FarSMTP: Near :NearSMTP:A- CopyArrivalDate yes Create Near Expunge Near Remove Near Sync Pull ~~~ > of course, a cleaner process would be the automaton marking these > messages with $Junk instead, but unfortunately mbsync doesn't support > syncing keywords, and you might have trouble comfortably editing them on > the near side anyway (the lack of a maildir standard for that is the > actual problem). > _______________________________________________ > isync-devel mailing list > isync-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/isync-devel >
_______________________________________________ isync-devel mailing list isync-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/isync-devel
