the algorithm is symmetrical, comparing the msgids that belong to the
paired uids. so it doesn't matter for recovering one side if the other
side's uidvalidity also changed. it does however impact our ability to
say on which side the change was genuine.
the pointless limitation was presumably a vestige from an earlier
iteration.
amends 77acc26 and 594e60b.
commit acd6b4b0 ("simplify/fix recursive maildir listing") argued that
listing INBOX when it is encountered while listing Path would be
unnecessary, as the caller would list it separately anyway if requested.
however, it is actually documented that Patterns will implicitly match
INBOX nested into Path. so revert that commit.
REFMAIL: 20240818002409.4c918eb4@inari
tell explicitly that the box cannot be opened _any more_, so it's clear
that Delete, rather than Create, would apply.
fwiw, it would be preferable to actually differentiate between absent
mailboxes and ones that fail to open for other reasons. but
unfortunately, IMAP doesn't report the difference (gmail has a
non-standard [NONEXISTENT] response code, though).
this shortens the release checklist and reduces commit churn.
for the date we use configure's timestamp. this should reflect the
package's creation time and be consistent with the version.
i found a neat trick to do it with the C pre-processor after all.
this makes the enum definitions themselves arguably somewhat less
legible, but on the upside the build system becomes simpler, and IDEs
can build/update their code models without having to (re-)build the
project first.
somewhat as a side effect, this gives bit enums proper names, so we
don't need to refer to them by cryptic prefixes anymore.
amends 6a78e2c5f.
the CHECK command doesn't do what i thought; the formulation in the
specs was ambiguous - it really checks for new mail, rather than
committing, and each operation is supposed to be atomic. inefficient,
but safe. IMAP4rev2 eliminates the command altogether, subsuming its
function under NOOP.
consequently, the commit callback doesn't make sense for imap.
in principle, we could use it to coalesce multiple STOREs to counter the
inefficiency, but that won't happen any time soon, and the
implementation would look rather differently anyway.
as a "side effect", this fixes an assertion failure in imap_close_box()
when all flag sets failed (e.g., b/c the box was read-only), as their
callbacks would be short-cut in front of the completion of the CHECK
command, which was not sequenced before the close_box() call.
This reverts commit cfaa4848dd.
if the SELECT command fails even though the box was LISTed, then the
error cause is obviously not that box is absent, and so we should not
attempt to CREATE it.
while this actually works due to the array size being zero, it's
undefined behavior which makes gcc eliminate a subsequent null check in
the calling function.
the BNF specifies "(SP DIGIT) / 2DIGIT" for the date-day-fixed symbol,
but "*SP 1*DIGIT" matches that closely enough for parsing purposes.
REFMAIL: CYYDEEVZ8CCT.2M1T7XKT45HH8@jonas.vautherin.ch
true asynchronicity is actually fairly useless, as it's unlikely that
both Stores in a Channel use IMAP, and both host resolutions take
particularly long - the main objective is imposing the Timeout setting.
however, we can't just use setjmp()+alarm(), as longjmp()ing out of
getaddrinfo() is undefined, as it may for example free() just at the
wrong time. so we go for the real thing.
this implementation just fork()s out a process which uses getaddrinfo()
(or gethostbyname()) per lookup. this isn't particularly scalable, but
as we don't expect a lot of lookups, it seems adequate.
this generally went unnoticed, as the tunnel usually terminates right
before we exit anyway. however, if multiple Channels are synced, it may
become visible.
this is a "shotgun" implementation, where the main loop just reaps all
unclaimed children.
arguably, it would be cleaner if each socket actually tracked its own
process, but getting synchronous kills+waits right is tricky, so we
continue to pretend that there is no process as far as the socket layer
is concerned.
poll()/select() are not restartable, so they need EINTR handling now
that SIGCHLD is actually delivered.
the mainloop-based refresh timer keeps spinning even if there is no
update. overload stats_steps to signal whether a refresh is needed.
amends 8fbc4323.
this got lost in d5a5da947.
this also simplifies a nested condition, where the logic has previously
been, but isn't applicable any more.
REFMAIL: 87fsjloz05.fsf@wavexx.thregr.org
that is, Path not ending with a slash.
pedantically, this is a bugfix, as the manual already suggested that
this is possible (and at least one user got the hint, though he was
disappointed).
the IMAP driver already supports this.
it was never documented, and i can't really think of a case where
someone would actually want it, as the MUA side of things would be just
weird. additionally, the case of Path being Inbox+'/' did not work
anyway. will reconsider and fix the latter case if someone complains.
reverts 98bd2b11.
there is no need to call maildir_list_{path,inbox}() from
maildir_list_recurse(), as maildir_list_store() will do that anyway -
if it's actually requested, that is. this means that this removes the
implicit listing when Inbox is nested into Path, or vice versa. this is
actually correct, as the Patterns matching would throw away the non-
requested boxes anyway.
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>.
the new one isn't an exhaustive set anymore, but a delta to the default
(or previous setting). this has the advantage that new versions aren't
automatically disabled anymore as soon as mbsync learns about them if
the user has a setting they fail to adjust.
report them as errors (not warnings), let them cause a non-zero exit
code, and in the case of trashing, prevent the subsequent expunge. the
exception are messages that just disappeared below our feet.
the purpose of these checks is preventing triggering more driver calls,
while immediate followups to already completed calls should be still
made.
note that some of the checks are strictly speaking redundant, as
chaining into a next phase will return immediately anyway when the
other side isn't ready yet. but we keep them for clarity.
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>.
Oswald Buddenhagen
Ludovico Gerardi