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
eventually will - thanks Microsoft!) you'll still need to remember to find
and reset the UidValidity values in the .mbsyncstate files.

Best wishes,
Marton

On Thu, 15 Aug 2024, 00:05 Laurent Michel, <l...@thorgal.homelinux.org>
wrote:

> 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 woods!
>
> —
> Laurent
>
> On 14 Aug 2024, at 18:12, Marton Balazs wrote:
>
> ooops, forgot to cc the List :-)
>
> ----- Forwarded message from Marton Balazs balm...@gmail.com -----
>
> Date: Wed, 14 Aug 2024 23:10:57 +0100
> From: Marton Balazs balm...@gmail.com
> To: Laurent Michel l...@thorgal.homelinux.org
> Subject: Re: Issue with Office365
>
> Do you have
> ~/.mbsync/ ?
>
> My .mbsyncrc starts with
> SyncState *
>
> meaning the sync state files .mbsyncstate are in the local maildir
> folders. Without this it seems you'll have them in ~/.mbsync/ , so you may
> need to find and edit the UidValidity parameters there somewhere?
>
> "
> SyncState {*|path}
>
> Set the location of this Channel’s synchronization state files. * means
> that the state should be saved in a file named .mbsyncstate in the near
> side mailbox itself; this has the advantage that you do not need to handle
> the state file separately if you delete the mailbox, but it works only with
> Maildir mailboxes, obviously. Otherwise this is interpreted as a string to
> prepend to the near side mailbox name to make up a complete path.
> This option can be used outside any section for a global effect. In this
> case the appended string is made up according to the pattern
> :far-store:far-box_:near-store:near-box (see also FieldDelimiter below).
> (Global default: ~/.mbsync/).
> "
> https://isync.sourceforge.io/mbsync.html
>
> Best wishes,
> Marton
>
> On Wed, Aug 14, 2024 at 04:11:03PM GMT, Laurent Michel wrote:
>
> 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 /home/ldm/bin/oauth2ms
> AuthMechs XOAUTH2
> TLSType IMAPS
> PipelineDepth 1
> Remote storage
>
> IMAPStore work-remote
> Account work
> Local storage
>
> MaildirStore work-local
> SubFolders Maildir++
> Inbox ~/FOO/work/Inbox
>
> Channel work-inbox
> Far :work-remote:"INBOX"
> Near :work-local:INBOX
> Patterns *
> Create Near
> Sync None
> Expunge None
> Remove None
>
> But it ended with the same UIDVALIDITY complain:
>
> ldm@pildm:~ $ mbsync -aV
> Reading configuration file /home/ldm/.mbsyncrc
> Channel work-inbox
> Opening far side store work-remote...
> Resolving outlook.office365.com...
> Opening near side store work-local...
> Connecting to outlook.office365.com (52.96.109.130:993)...
> Connection is now encrypted
> Logging in...
> Authenticating with SASL mechanism XOAUTH2...
> Opening far side box INBOX...
> Opening near side box INBOX...
> Loading far side box...
> Loading near side box...
> near side: 0 messages, 0 recent
> far side: 1973 messages, 0 recent
> Error: channel work-inbox, near side box INBOX: Unable to recover from
> UIDVALIDITY change.
> Processed 1 box(es) in 1 channel(s).
>
> I’m puzzled. This is what the foo folder contains
>
> ldm@pildm:~ $ cd FOO/
> ldm@pildm:~/FOO $ ls
> work
> ldm@pildm:~/FOO $ cd work/Inbox/
> cur/ new/ tmp/
> ldm@pildm:~/FOO $ cd work/Inbox/
> ldm@pildm:~/FOO/work/Inbox $ ls -al
> total 24
> drwx------ 5 ldm ldm 4096 Aug 14 15:55 .
> drwx------ 3 ldm ldm 4096 Aug 14 15:55 ..
> drwx------ 2 ldm ldm 4096 Aug 14 15:55 cur
> drwx------ 2 ldm ldm 4096 Aug 14 15:55 new
> drwx------ 2 ldm ldm 4096 Aug 14 15:55 tmp
> -rw------- 1 ldm ldm 13 Aug 14 15:55 .uidvalidity
> ldm@pildm:~/FOO/work/Inbox $ cat .uidvalidity
> 1723665330
> 0
>
> On 14 Aug 2024, at 15:45, Marton Balazs wrote:
>
> 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
> MS to there using
>
> Patterns *
> Create Near
> Sync None
> Expunge None
> Remove None
>
> This creates the folders and the
> .mbsyncstate
> .uidvalidity
>
> files in them but won't download the actual emails so it runs fast. I don't
> know why you never mentioned .mbsyncstate? This is the one I need to look
> at: if its first line like
>
> FarUidValidity 14
>
> differs between the pulled empty folders and my existing local email
> folder, that's when I get the errors. So, I manually edit this parameter in
> my local emails folder to match the one I just pulled from MS and magically
> everything works ok again.
>
> I'm not sure you have the same problem but it would be worth looking at the
> .mbsyncstate files and the FarUidValidity parameter in them.
>
> Best wishes,
> Marton
>
> On Wed, Aug 14, 2024 at 02:50:19PM GMT, Laurent Michel wrote:
>
>     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/ldm/.mbsyncrc
>     Channel work-inbox
>     Opening far side store work-remote...
>     Resolving outlook.office365.com...
>     Opening near side store work-local...
>     Connecting to outlook.office365.com (52.96.97.162:993)...
>     Connection is now encrypted
>     Logging in...
>     Authenticating with SASL mechanism XOAUTH2...
>     Opening far side box INBOX...
>     Opening near side box INBOX...
>     Loading far side box...
>     Loading near side box...
>     near side: 0 messages, 0 recent
>     far side: 1971 messages, 0 recent
>     Error: channel work-inbox, near side box INBOX: Unable to recover from
>     UIDVALIDITY change.
>     Processed 1 box(es) in 1 channel(s),
>     pulled 0 new message(s) and 0 flag update(s),
>     expunged 0 message(s) from near side,
>     pushed 0 new message(s) and 0 flag update(s),
>     expunged 0 message(s) from far side.
>
>     As you can see, it’s not an authentication issue but an UIDVALIDITY
>     issue. I
>     looked on the web and tried pretty much every single thing I found,
>     including
>     deleting my local copy in its entirety:
>
>     rm -rf ~/Mail
>
>     And let it redownload everything. The .uidvalidity file(s) are held
>     within the
>     ~/Mail
>
>     and rerunning the command above after atomizing the folder yields this
>     content
>
>     ldm@pildm:~ $ cd Mail/
>     ldm@pildm:~/Mail $ tree
>     .
>     └── work
>     └── In
>     ├── cur
>     ├── new
>     └── tmp
>
>     6 directories, 0 files
>     ldm@pildm:~/Mail $ ls -al
>     total 12
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 .
>     drwxr-xr-x 57 ldm users 4096 Aug 14 14:44 ..
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 work
>     ldm@pildm:~/Mail $ ls -alR
>     .:
>     total 12
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 .
>     drwxr-xr-x 57 ldm users 4096 Aug 14 14:44 ..
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 work
>
>     ./work:
>     total 12
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 .
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 ..
>     drwx------ 5 ldm ldm 4096 Aug 14 14:44 In
>
>     ./work/In:
>     total 24
>     drwx------ 5 ldm ldm 4096 Aug 14 14:44 .
>     drwx------ 3 ldm ldm 4096 Aug 14 14:44 ..
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 cur
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 new
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 tmp
>     -rw------- 1 ldm ldm 13 Aug 14 14:44 .uidvalidity
>
>     ./work/In/cur:
>     total 8
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 .
>     drwx------ 5 ldm ldm 4096 Aug 14 14:44 ..
>
>     ./work/In/new:
>     total 8
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 .
>     drwx------ 5 ldm ldm 4096 Aug 14 14:44 ..
>
>     ./work/In/tmp:
>     total 8
>     drwx------ 2 ldm ldm 4096 Aug 14 14:44 .
>     drwx------ 5 ldm ldm 4096 Aug 14 14:44 ..
>
>     I even have renamed my inbox from INBOX to “In” in fear that a hidden
>     file was
>     lurking somewhere. But no dice.
>
>     running
>
>     mbsync -aVD
>
>     produces a huge output. Only showing the very end below
>
>     uid=1051965 flags=S size=0 tuid=?
>     uid=1052014 flags=S size=0 tuid=?
>     uid=1052020 flags=S size=0 tuid=?
>     uid=1052026 flags=S size=0 tuid=?
>     uid=1052032 flags=RS size=0 tuid=?
>     uid=1052050 flags=RS size=0 tuid=?
>     uid=1052062 flags=S size=0 tuid=?
>     uid=1052073 flags=S size=0 tuid=?
>     uid=1052079 flags=S size=0 tuid=?
>     uid=1052085 flags=S size=0 tuid=?
>     uid=1052099 flags=S size=0 tuid=?
>     uid=1052104 flags=S size=0 tuid=?
>     uid=1052112 flags=S size=0 tuid=?
>     far side: 1971 messages, 0 recent
>     matching messages on far side against sync records
>     trying to re-approve uid validity of near side
>     Error: channel work-inbox, near side box INBOX: Unable to recover from
>     UIDVALIDITY change.
>     F: [ 7] Enter cancel_cmds
>     F: [ 7] Callback enter cancel_cmds
>     F: [ 7] Callback leave cancel_cmds
>     F: [ 7] Leave cancel_cmds
>     N: [ 8] Enter cancel_cmds
>     N: [ 8] Callback enter cancel_cmds
>     F: Enter free_store
>     F: Leave free_store
>     N: Enter free_store
>     N: Leave free_store
>     F: >>> 8 LOGOUT
>     N: [ 8] Callback leave cancel_cmds
>     N: [ 8] Leave cancel_cmds
>     F: [ 5] Callback leave load_box
>     F: * BYE Microsoft Exchange Server IMAP4 server signing off.
>     F: 8 OK LOGOUT completed.
>     Processed 1 box(es) in 1 channel(s),
>     pulled 0 new message(s) and 0 flag update(s),
>     expunged 0 message(s) from near side,
>     pushed 0 new message(s) and 0 flag update(s),
>     expunged 0 message(s) from far side.
>     ldm@pildm:~/Mail $
>
>     There are 1971 messages in my inbox, so that value we see above is
>     correct. I
>     have no idea why this is failing. Any help would be much appreciated.
>
>     My .mbsyncrc is pretty vanilla (just removing my address)
>
>     ldm@pildm:~ $ cat .mbsyncrc
>     #################################
>     ######## Account work ###########
>     #################################
>
>     IMAPAccount work
>     Host outlook.office365.com
>     User xxxxx@yyyy.zzzzz
>     PassCmd /home/ldm/bin/oauth2ms
>     AuthMechs XOAUTH2
>     TLSType IMAPS
>     PipelineDepth 1
>
>     Remote storage
>
>     IMAPStore work-remote
>     Account work
>
>     Local storage
>
>     MaildirStore work-local
>     SubFolders Maildir++
>     Inbox ~/Mail/work/In
>
>     Channel work-inbox
>     Far :work-remote:"INBOX"
>     Near :work-local:INBOX
>     Create Both
>     Sync Pull Push New Flags
>     Expunge Both
>
>     Group work
>     Channel work-inbox
>
>     The only .uidvalidity file I have is created in that tree and contains
>     the
>     following
>
>     ldm@pildm:~ $ cat Mail/work/In/.uidvalidity
>     1723661072
>     0
>
>     Help?
>
>     —
>     Laurent
>
>     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>
>     isync-devel mailing list
>     isync-devel@lists.sourceforge.net
>   https://lists.sourceforge.net/lists/listinfo/isync-devel
>
> ----- End forwarded message -----
> ------------------------------
>
> 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

Reply via email to