this finally makes us compliant with IMAP4rev1. how fitting that the
meanwhile released IMAP4rev2 demoted UTF-7 to legacy status ...
based on a patch by Georgy Kibardin <georgy@kibardin.name>.
this is only a partial solution for reporting changes, but it's
adequate if the goal is merely triggering a bulk action, like
re-indexing the local store.
inspired by patches posted by Yuri D'Elia <wavexx@thregr.org>.
the underlying metaphor refers to an inhumane practice, so using it
casually is rightfully offensive to many people. it isn't even a
particularly apt metaphor, as it suggests a strict hierarchy that is
counter to mbsync's highly symmetrical mode of operation.
the far/near terminology has been chosen as the replacement, as it is a
natural fit for the push/pull terminology. on the downside, due to these
not being nouns, a few uses are a bit awkward, and several others had to
be amended to include 'side'. also, it's conceptually quite close to
remote/local, which matches the typical use case, but is maybe a bit too
suggestive of actually non-existing limitations.
the new f/n suffixes of the -C/-R/-X options clash with pre-existing
options, so direct concatenation of short options is even less practical
than before (some suffixes of -D already clashed), but doing that leads
to unreadable command lines anyway.
as with previous deprecations, all pre-existing command line and config
options keep working, but yield a warning. the state files are silently
upgraded.
while it's correct that mbsync doesn't strictly need to support both
Inbox and Path in a single Channel due to being able to Group Channels,
this "simplification" would have some undesirable effects:
- the concept is part of IMAP and provides a certain level of
"zero-conf" (in particular via NAMESPACE). having to set up two Stores
and associated Channels for one Account to reproduce this
functionality would add quite some redundancy to common
configurations.
- implementing MapInbox and move detection across Channels would add
significant complexity.
one reason why one would want this change in the first place is to get
rid of the ambiguity of INBOX appearing right under Path. this could be
avoided by either using a different magic prefix that cannot appear in
actual mailbox names, or requiring a prefix for boxes inside path as
well. neither approach seems worth the effort, given that nesting
"INBOX" under Path causes problems for some other IMAP clients anyway.
this is relevant only when listing an IMAP Store's contents, as that's
the only place where we aren't imposing the spelling ourselves.
we need to be careful not to treat our own canonical (prefix-stripped
and always slash-delimited) box names like that; codify that in
comments.
this reveals that commit 6f2160f1 may be deemed to have been incorrect -
the TODO item was ambiguous, and could quite possibly have meant this
fix. unsurprisingly, 380ccdd4 re-introduced it with more explicit
wording.
trashing many messages at once inevitably overtaxes m$ exchange, and the
connection breaks. without any progress tracking, it would restart from
scratch each time, which would lead to a) it never finishing and b) many
copies of the messages in the trash.
full transactions as we do for "proper" syncing would be over the top,
as it's not *that* bad if some messages get duplicated in the trash. so
we record only the messages for which trashing completed, thus allowing
some overlap between the attempts.
patch initially by Jack Stone <jwjstone@fastmail.fm>,
cleaned up by Jan Synacek <jsynacek@redhat.com>,
... and then almost completely rewritten by me. ^^
this is *our* magic string, not IMAP's.
ok, admittedly, we *also* send it to IMAP, but that's just convenience.
actually making it case insensitive would improve interoperability with
thunderbird (which interprets INBOX even if qualified), but would break
existing setups (including mine).
in fact, UIDNEXT (and UIDVALIDITY) null is *not* allowed (see RFC3501
section 9). them popping up nonetheless was a dovecot bug (which would
also confuse dovecot itself).
having it in as a workaround was no good either, as quite some other
code in mbsync assumes that UIDs are not null.
This reverts commit e1fa867 and most of 39006d7.
-REFMAIL: 4CA62BA1.4020104@lemma.co.uk
- introduce sys_error() and use it instead of perror() and
error(strerror()) in all expected error conditions
- perror() is used only for "something's really wrong with the system"
kind of errors
- file names, etc. are quoted if they are not validated yet, so e.g. an
empty string becomes immediately obvious
- improve and unify language
- add missing newlines
as opposed to earlier threats, BerkDB was not entirely dropped; i
suppose the isync 0.7 -> 0.8 change had a reason, so i added an
alternative UID storage scheme.
note that BDB 4.0 is not sufficient, as the db->open function changed in
an incompatible way ...
i updated the debian packaging except for a changelog entry.
note that i removed the upgrade blurb, as upstream now has a smooth
upgrade path down to at least isync 0.4.
the uid for each message in the maildir is now stored in a dbm database
rather than the filename. this change was necessary because isync became
confused if you copied a message to another folder, in which case the uid
was invalid.
as a result of the above change, isync now acquires a mutex on the mailbox
to protect the dbm database from concurrent access.
main() was reworked to continue gracefully when an error is encountered, and
to always call maildir_close() so that the lock can be disabled, and the
database closed.
sync_mailbox() didn't consider MaxSize == 0 to mean "unlimited".
load_config() needs to print a newline in its error messages since
next_arg() kills the newline of the line that was read out of the config
file.
out if new mail arrives while in the process of downloading
noted in BUGS section of man page that if new mail arrives after the initial
message list has been retrieved from the IMAP server, that new mail will not
be fetched until the next invocation of isync.
configuration directives
added `Maildir' configuration command to specify the default location of the
user's mailboxes. If a relative path is used in a `Mailbox' command, this
path is used as a prefix.
