elaborate on expunging and trashing

This commit is contained in:
Oswald Buddenhagen 2013-12-14 12:37:11 +01:00
parent 4481702da3
commit 8b2bc912b4

View File

@ -20,7 +20,7 @@
\" As a special exception, mbsync may be linked with the OpenSSL library,
\" despite that library's more restrictive license.
..
.TH mbsync 1 "2013 Aug 3"
.TH mbsync 1 "2013 Dec 14"
..
.SH NAME
mbsync - synchronize IMAP4 and Maildir mailboxes
@ -167,7 +167,8 @@ under \fBPath\fR, including the "INBOX\fIdelim\fR" prefix.
.TP
\fBTrash\fR \fImailbox\fR
Specifies a mailbox (relative to \fBPath\fR) to copy deleted messages to
prior to expunging. See \fBINHERENT PROBLEMS\fR below.
prior to expunging.
See \fBRECOMMENDATIONS\fR and \fBINHERENT PROBLEMS\fR below.
(Default: none)
..
.TP
@ -483,6 +484,7 @@ does not exist.
.TP
\fBExpunge\fR {\fINone\fR|\fIMaster\fR|\fISlave\fR|\fIBoth\fR}
Permanently remove all messages [on the Master/Slave] marked for deletion.
See \fBRECOMMENDATIONS\fR below.
(Global default: \fINone\fR)
..
.TP
@ -549,6 +551,34 @@ in particular modern systems like ext4, btrfs and xfs. The performance impact
on older file systems may be disproportionate.
(Default: \fIyes\fR)
..
.SH RECOMMENDATIONS
Make sure your IMAP server does not auto-expunge deleted messages - it is
slow, and semantically somewhat questionable. Specifically, Gmail needs to
be configured not to do it.
.P
By default, \fBmbsync\fR will not delete any messages - deletions are
propagated by marking the messages as deleted on the remote store.
Once you have verified that your setup works, you will typically want to
set \fBExpunge\fR to \fBBoth\fR, so that deletions become effective.
.P
\fBmbsync\fR's built-in trash functionality relies on \fBmbsync\fR doing
the expunging of deleted messages. This is the case when it propagates
deletions of previously propagated messages, and the trash is on the target
store (typically your IMAP server).
.br
However, when you intend \fBmbsync\fR to trash messages which were not
propagated yet, the MUA must mark the messages as deleted without expunging
them (e.g., \fBMutt\fR's \fBmaildir_trash\fR option). Note that most
messages are propagated a long time before they are deleted, so this is a
corner case you probably do not want to optimize for. This also implies
that the \fBTrashNewOnly\fR and \fBTrashRemoteNew\fR options are typically
not very useful.
.P
If your server supports auto-trashing (as Gmail does), it is probably a
good idea to rely on that instead of \fBmbsync\fR's trash functionality.
If you do that, and intend to synchronize the trash like other mailboxes,
you should not use \fBmbsync\fR's \fBTrash\fR option at all.
..
.SH INHERENT PROBLEMS
Changes done after \fBmbsync\fR has retrieved the message list will not be
synchronised until the next time \fBmbsync\fR is invoked.