What I have been doing wrong with testing expunged emails, is working with linked copies of emails. Although thunderbird copies the message, it looks like the message is NOT copied but linked. If I drag 3 emails from my desktop to a folder INBOX/test4 and copy 1 message from INBOX to INBOX/test4. I have 4 messages in this folder. I now shift+del this folder. The expunged messages listing gives me the expected 3 messages doveadm -o mail_location=mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index mailbox status -u testtest 'messages vsize' '*' Sent messages=0 vsize=0 Drafts messages=0 vsize=0 INBOX/test2 messages=0 vsize=0 Junk messages=0 vsize=0 Trash messages=0 vsize=0 test3 messages=0 vsize=0 test1 messages=0 vsize=0 RESTORED messages=0 vsize=0 INBOX messages=3 vsize=18079344 Lets recover these: doveadm -v import -u testtest 'mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index' RESTORED ALL Now I have 3 messages back, as expected. From an end users perspective if you delete a folder with 4 emails, you want your restored backup to have 4 emails, not 3 because one is already somewhere else in your folder/mailbox structure. The reason for copying an email to a different folder is that it is important. You do not want to loose it, and you want to be able to find it there. It is wrong to assume that a user will notice that these emails are missing and should look for them elsewhere. Say you have folder for a court case, and you copy emails there relevant for the court case. How can you ever know after a restore that a few email are missing from the folder, and which ones. I think it is bad this email is currently 'lost'. I rather have an option in dovecot that disables this hidden 'deduplication' feature. I think this should be the default setting also. This current deduplication feature also is hazardous because if this one copy of the email gets corrupted on the storage, you have no copies left. That is exactly the opposite of what user wants to accomplish with creating a copy. Feature request: disable this automatic linking of emails between mailboxes. Feature request: set this as a default.
On 17. Mar 2021, at 13.39, Marc <Marc at f1-outsourcing.eu> wrote:> > The reason for copying an email to a different folder is that it is important. You do not want to loose it, and you want to be able to find it there. > It is wrong to assume that a user will notice that these emails are missing and should look for them elsewhere. > Say you have folder for a court case, and you copy emails there relevant for the court case. How can you ever know after a restore that a few email are missing from the folder, and which ones. > > I think it is bad this email is currently 'lost'. I rather have an option in dovecot that disables this hidden 'deduplication' feature. I think this should be the default setting also. > > This current deduplication feature also is hazardous because if this one copy of the email gets corrupted on the storage, you have no copies left. That is exactly the opposite of what user wants to accomplish with creating a copy. > > Feature request: disable this automatic linking of emails between mailboxes. > Feature request: set this as a default.mdbox is intended to be high performance mail storage, and this would make copying significantly slower. If you care more about reliability, maybe switch to sdbox or maildir instead? It would be easy enough to patch though: diff --git a/src/lib-storage/index/dbox-multi/mdbox-save.c b/src/lib-storage/index/dbox-multi/mdbox-save.c index ff6e4f77b0..b522951b1d 100644 --- a/src/lib-storage/index/dbox-multi/mdbox-save.c +++ b/src/lib-storage/index/dbox-multi/mdbox-save.c @@ -440,7 +440,7 @@ int mdbox_copy(struct mail_save_context *_ctx, struct mail *mail) ctx->ctx.finished = TRUE; if (mail->box->storage != _ctx->transaction->box->storage || - _ctx->transaction->box->disable_reflink_copy_to) + _ctx->transaction->box->disable_reflink_copy_to || TRUE) return mail_storage_copy(_ctx, mail); src_mbox = MDBOX_MAILBOX(mail->box); -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20210317/12a2120e/attachment.html>