Great!
I suspect the whole time the old UidValidity values were kept from
your ~/.mbsync/
folder. Turning on SyncState resulted in mbsync now disregarding those and
starting with fresh values in the new .mbsyncstate files.
That is, the next time you run into this error (and, believe me you
eventu
Thanks.
I tried a few things based on your email.
First I do not have any file anywhere going by the name
“.mbsyncstate”
```
ldm@pildm:~ $ find . -name ".mbsyncstate"
ldm@pildm:~ $
```
I changed my mbsyncrc as you suggested to
```
IMAPAccount work
Host outlook.office365.com
User …..
PassCmd
You are likely going to be a life savior for me. I added the SyncState
stanza
and it started synchronizing! Fingers crossed that it will do the whole
bit, but that is amazing.
A .mbsyncstate(.journal | .lock | .new) set of files appeared too.
Thank you so much, it seems like I’m out of the woo
ooops, forgot to cc the List :-)
- Forwarded message from Marton Balazs -
Date: Wed, 14 Aug 2024 23:10:57 +0100
From: Marton Balazs
To: Laurent Michel
Subject: Re: Issue with Office365
Do you have
~/.mbsync/ ?
My .mbsyncrc starts with
SyncState *
meaning the sync state files .mbsyn
As far as I understand, every now and then MS screws up UidValidity, which it
really shouldn't do -- but it's MS. On these occasions Mbsync usually recovers
most of my folders from this but on a few I get the error you mentioned. I then
create an empty directory and pull all of my folders from M
Dear All,
I had isync running flawlessly for a few years with OAUTH2. Recently, it
seems like my organization must have done an “upgrade” to Office365.
And now, everything is broken on my end.
Specifically, each sync end as so:
```
ldm@pildm:~ $ mbsync -aV
Reading configuration file /home/ld
