Gotcha. Though, I must say I did not have a “.mbsync” folder. That is still mysterious to me (I compilde isync from the git repo directly, main branch). No matter, you saved me! Thank you!

The IT department does not know what they are doing. Things break when they go to the next version of software from the evil empire. I know it will happen again. Still, very glad to have the functionality restored.

Thanks again!

All the best,

—
 Laurent


On 15 Aug 2024, at 2:17, Marton Balazs wrote:

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