On Thu, 14 Nov 2019 at 14:01:33 +0100, Jonas Smedegaard wrote: > interimap --config hb --delete --target=database,local INBOX > interimap --config hb > > ..which seemingly succeeded in throwing away local copy of INBOX
That confuses me even more, ‘--target=database,local’ is a no-op for 0.4-1 because there is no target with that name. That should be be ‘--target=database --target=local’ instead (comma-separated targets are allowed since ce35ea5 but that code hasn't been released yet) as written earlier. However, unlike what I claimed before, deleting INBOX will only succeed for the database target, as RFC 3501 src 6.3.4 explicitly forbids this. Sigh. (A workaround to delete one's INBOX is to rename it to something else and delete the new name.) > and re-fetching it from remote INBOX, I guess only the new remote messages were copied? Could you confirm that INBOX's local (resp. remote) UIDVALIDITY is 1571588814 (resp. 1154884797)? However it's beyond me why the remote UIDVALIDITY appears to have changed again back to its previous value. Are Dovecot's remote index files stored on another drive, that might not be mounted all the time? > ..because surprisingly to me, attempting to throw away local copy of > _Drafts_ failed: > > jonas@auryn:~$ interimap --config hb --delete --target=database,local Drafts Should work with `--target=database --target=local --delete Drafts`; you should see notifications of successful deletion in the DB and on the local server. > Am I perhaps misunderstanding and UIDVALIDITY is tied to whole account, > not each mailbox? Nope, this is indeed a per-mailbox attribute (like UIDNEXT annd HIGHESTMODSEQ). Or more precisely, a “mailbox” is the combination of a *name* and an UIDVALIDITY. > local: S: * STATUS Drafts (UIDNEXT 962 UIDVALIDITY 1571588832 HIGHESTMODSEQ 4) > remote: S: * STATUS Drafts (UIDNEXT 962 UIDVALIDITY 1571588832 HIGHESTMODSEQ > 4) > local: Update last clean state for Drafts: (UIDVALIDITY 1571588832 > HIGHESTMODSEQ 1 UIDNEXT 1) > lUIDVALIDITY|lUIDNEXT|lHIGHESTMODSEQ|rUIDVALIDITY|rUIDNEXT|rHIGHESTMODSEQ > 1571588832 |1 |1 |1154884797 |962 |4 Thanks, so the local values make sense for a mailbox created on Oct 20, which had never been populated by the time interimap last synced it. Right now the UIDVALIDITY/UIDNEXT/HIGHESTMODSEQ values appear to be identical on both servers, oddly set to their respective maximum. That's extremely unlikely the doing of an IMAP client (it'd need to delete Drafts on the remote server, recreate it at 1571588832s — or be lucky enough that the server picks that UIDVALIDITY, then on both servers create 961 messages in 3 batches, mark them all as deleted, then expunge). > jonas@auryn:~$ ssh mail.homebase.dk doveadm mailbox status "messages uidnext > uidvalidity highestmodseq firstsaved" Drafts > Drafts messages=0 You need to double quote/escape the spaces in the string query, otherwise it runs `doveadm mailbox status messages uidnext uidvalidity highestmodseq firstsaved Drafts` (‘uidnext’ and beyond interpreted as mailbox names). Could you please also check that the UIDVALIDITY value is found on the second field (prefixed with a ‘V’) of the first line [0] of /path/to/Maildir/.Drafts/dovecot-uidlist both locally and remotely? Would be nice to see the output of `stat -c"%y %z"` on these files, also. > I have triple-checked, and am preeetty sure that I completely stopped > using dsync after I engaged with interimap. Cannot verify for certain > e.g. by examining .bash_history because I use a local wrapper script, > but all lines in that wrapper script which previously called dsync was > commented out before I initially ran interimap (and that commenting out > is what I triple-checked). OK, thanks for checking. Can't explain why the new internal mailbox state seems to be a mix of the old remote and local ones though :-( > Possibly related sidenote: I noticed suspecious interimap summary notes > about bandwidth consumption that seemed flipped around (new messages > transfered from remote to local, but interimap saying that remote > received far more than sending, and local received far less than > sending). Possible local/remote mixup in interimap code somewhere? > Sidenote only here - if I notice again I will report separately! I hope the test suite would have caught delivery to the wrong server (there are unit tests as well as randomized tests) :-P The stats stuff is just cosmetic so there are no tests though; I understand your confusion, but these numbers come from interimap's perspective: recv (resp. sent) stands for received by (resp. to) interimap from the server, so when remote a message as copied locally the “remote” IMAP client *receives* a large FETCH reply and the “local” one *sends* a large literal in an APPEND command. That was my thinking at least :-) -- Guilhem. [0] https://wiki.dovecot.org/MailboxFormat/Maildir
signature.asc
Description: PGP signature
