offlineimap/mbsync state files compatibility
raphael.droz at gmail.com
Tue Dec 8 00:54:29 GMT 2015
I've used OfflineIMAP for some months, but I now intend to switch to
mbsync¹ (the later let me avoid syncing email deleting from master to slave).
I would like to avoid downloading again GB of emails still in the remote
The most obvious way seem to convert the OfflineIMAP repository to a
mbsync repository. And the first step is state files.
========= OfflineIMAP keeps them is a directory named after the "account".
Then one file per directory, whose header is
> OFFLINEIMAP LocalStatus CACHE DATA - DO NOT MODIFY - FORMAT 1
Indexes are stored in a directory named like
which contains a long integer (folder UIDVALIDITY)
Email files follow the pattern
========= mbsync keeps many files in .mbsync/ named as:
<remote account>:<remote!folder>:<local account>:<local!folder>
The first line contain somehow indexes/timestamp:
> 631491624:7575 1368096631:0:0
followed by 3-columns lines, sample:
> 72 10 RS
> 81 14 S
> 85 15 RS
> 87 16 S
> 169 31 S
> 865 140 F
The .uidvalidity file stores the latest timestamp and id
(even before the state file is full created)
Email files follow the pattern:
I guess email file naming isn't that important unrelated since none of
the tools checks file existence before (re)downloading an email, but
that's a guess.
========= what can be done
Switching from OfflineIMAP
to the two values inside mbsync's .uidvalidity file is trivial
========= what must probably be done
What are the 2+3 values, in the header of mbsync's folder state file?
And how OfflineIMAP's <repostory>/FolderValidity/<folder> could be
converted/expanded to these 5 values?
========= other questions:
- My goal being to continue, with mbsync, a synchronisation started for
backup-purposes with OfflineIMAP, what part of the state could be
omitted that mbsync could intelligently deduce?
- What the 2nd column of the mbsync state file is useful for?
- Why mbsync .uidvalidity file does not contain the value that
OfflineIMAP calls folder UIDVALIDITY?
- Any efforts to document (standardize?) these internal data/state files?
¹ explanation: offlineimap does not let me have an append/change-only
local repository (email deleted remotely are forcefully deleted locally)
More information about the OfflineIMAP-project