Hey -

I tried out vsync yesterday and today. I see it uses condstore so I'm pretty
thrilled about that. I am able to do a full initial sync with no issues, but if
I *immediately* do a second sync, I delete remote mailboxes (luckily I'm on
fastmail which lets me do a restore :).

Happy to help debug on my end! I have an easy to restore situation so I'm fine
ruining it all for the sake of debugging.

--
Tim

Steps to recreate:
$ vsync
$ vsync

Tail of the trace:

03:59:35 [INFO] Using 3 threads to sync 26 mailboxes
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:371] Syncing Archive in main thread
03:59:35 [DEBUG] (2) vomit_sync: Connecting to imap.fastmail.com:993
03:59:35 [INFO] loading state for .Archive
03:59:35 [DEBUG] (3) vomit_sync: Connecting to imap.fastmail.com:993
03:59:35 [INFO] done loading state for .Archive
03:59:35 [TRACE] (1) vomit_sync::sync: [src/sync.rs:555] Nothing to do for Archive
03:59:35 [DEBUG] (3) vomit_sync: Logging in as tim@timculverhouse.com
03:59:35 [DEBUG] (2) vomit_sync: Logging in as tim@timculverhouse.com
03:59:35 [DEBUG] (1) vomit_sync: Synced Archive in 325ms
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:371] Syncing Drafts in main thread
03:59:35 [INFO] loading state for .Drafts
03:59:35 [INFO] done loading state for .Drafts
03:59:35 [TRACE] (3) vomit_sync: [src/lib.rs:239] Syncing INBOX in worker thread 2
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:239] Syncing INBOX/Cadence in worker thread 1
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:207] Deleting remote mailbox INBOX/Cadence
03:59:35 [INFO] loading state for .
03:59:35 [INFO] done loading state for .
03:59:35 [TRACE] (1) vomit_sync::sync: [src/sync.rs:555] Nothing to do for Drafts
03:59:35 [DEBUG] (1) vomit_sync: Synced Drafts in 42ms
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:371] Syncing INBOX/Charlie in main thread
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:207] Deleting remote mailbox INBOX/Charlie
03:59:35 [DEBUG] (2) vomit_sync: Synced INBOX/Cadence in 62ms
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:239] Syncing INBOX/Gmail in worker thread 1
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:207] Deleting remote mailbox INBOX/Gmail
03:59:35 [TRACE] (3) vomit_sync::sync: [src/sync.rs:581] In INBOX: LocalChanges { added: [], deleted: {}, changed: {} }
03:59:35 [TRACE] (3) vomit_sync::sync: [src/sync.rs:593] Performing refresh fetch for INBOX (427789 -> 427796)
03:59:35 [DEBUG] (1) vomit_sync: Synced INBOX/Charlie in 57ms
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:371] Syncing INBOX/lists in main thread
03:59:35 [TRACE] (1) vomit_sync: [src/lib.rs:207] Deleting remote mailbox INBOX/lists
03:59:35 [DEBUG] (2) vomit_sync: Synced INBOX/Gmail in 55ms
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:239] Syncing INBOX/lists/aerc-devel in worker thread 1
03:59:35 [TRACE] (2) vomit_sync: [src/lib.rs:207] Deleting remote mailbox INBOX/lists/aerc-devel
03:59:35 [DEBUG] (1) vomit_sync: Synced with imap.fastmail.com:993 in 919ms
03:59:35 [ERROR] Error during sync: IMAP error: No Response: [HASCHILDREN] Mailbox has inferior hierarchical names

Hey there!

On 11/12/22 05:10, Tim Culverhouse wrote:
> I tried out vsync yesterday and today. I see it uses condstore so I'm pretty
> thrilled about that. I am able to do a full initial sync with no issues, but if
> I*immediately*  do a second sync, I delete remote mailboxes (luckily I'm on
> fastmail which lets me do a restore 😄.

Ouch. All glory to Fastmail's restore mechanism, and thanks a lot for 
reporting this without yelling at me :)

I just looked at this, and I think I know the issue. It seems like 
Fastmail is using a slash as the hierachy delimiter as opposed to the 
(slightly) more common dot. It is totally a feature of IMAP that the 
hierachy delimiter can be set arbitrarily by the server, but one I had 
completely neglegted so far. You might say, I sort of forgot about it...

I will release a new version ASAP that just aborts immediately in this 
case, to prevent an influx of angry non-Fastmail-users. Then, hopefully 
not much after that, I will release a version that actually handles this 
correctly. I'd be delighted if you'd be up for giving it another chance 
then :)

Thanks again,
Conrad

On Sun Nov 13, 2022 at 1:19 PM CST, Conrad Hoffmann wrote:
> Ouch. All glory to Fastmail's restore mechanism, and thanks a lot for 
> reporting this without yelling at me :)

No problem :).

> I will release a new version ASAP that just aborts immediately in this 
> case, to prevent an influx of angry non-Fastmail-users. Then, hopefully 
> not much after that, I will release a version that actually handles this 
> correctly. I'd be delighted if you'd be up for giving it another chance 
> then :)

I'd be happy to try it out again, let me know when it's ready and I'll give it a
go.

Thanks!

--
Tim

Hey again,

before I unleash a new version, I'd be curious: does your Fastmail setup 
permit having dots (`.`) in mailbox names? E.g., can you have folder 
"lists/sr.ht"?

I've set up a Dovecot instance for testing, but it does not allow dots 
even when using the slash as delimiter. There is apparently a plugin 
that one can use to make it work, but it does some non-standard stuff. 
Would be great to get an idea of how widely this might be used before I 
accidentally delete people's mail again ;)

Thanks a lot,
Conrad

On Thu Nov 17, 2022 at 3:55 AM CST, Conrad Hoffmann wrote:
> Hey again,
>
> before I unleash a new version, I'd be curious: does your Fastmail setup 
> permit having dots (`.`) in mailbox names? E.g., can you have folder 
> "lists/sr.ht"?

Hey Conrad -

Yep, fastmail allows dots in folder names.

--
Tim

On 11/13/22 20:33, Tim Culverhouse wrote:
> I'd be happy to try it out again, let me know when it's ready and I'll give it a
> go.

There it is. I just released v0.7.0, which handles arbitrary delimtiers 
(and also dots in mailbox names). I also added a little debugging 
option, so you can verify this without deleting your mail again ;)

In your case, simply run `vsync` once, for the initial pull. Then, the 
second time, run `vsync --list`. It will show you local and remote 
mailboxes and which actions it _would_ perform on any of them. Should 
that output include `DeleteLocal` for any mailbox, I would kindly ask 
you to send it to me for debugging purposes :)

Jokes aside, I tested this a bunch, but especially in case of odd 
characters in mailbox names there could be issues that I missed. If the 
output of `--list` looks sane, then syncing again is safe.

Thanks again for the report and the help,
Conrad

On Fri Nov 18, 2022 at 3:40 PM CST, Conrad Hoffmann wrote:
> There it is. I just released v0.7.0, which handles arbitrary delimtiers 
> (and also dots in mailbox names). I also added a little debugging 
> option, so you can verify this without deleting your mail again ;)
>
> In your case, simply run `vsync` once, for the initial pull. Then, the 
> second time, run `vsync --list`. It will show you local and remote 
> mailboxes and which actions it _would_ perform on any of them. Should 
> that output include `DeleteLocal` for any mailbox, I would kindly ask 
> you to send it to me for debugging purposes :)

Works as expected! Thanks for fixing that. Due to some mailbox sharing in
fastmail, I have some mailboxes with '@' in the name and those sync just fine,
too.

Thanks again!

--
Tim