offlineimap smart backup synchronization = bidirectional synchronization without deleting any messages

[proxym]

After I changed `no-delete-local` back to `no` ALL previously
not-deleted messages (because of `no-delete-local yes`) are deleted
from my local repository.
This patch IS TOO DANGEROUS in case of no back synchronisation of
messages to remote imap repository.

2012/12/18 proxym <wproxym at gmail.com>:
> OK. Thanks.
>
> I removed this from patch:
> +        import sys
> +        sys.exit()
>
> And I placed
> no-delete-local = yes
> to [Account main] section.
>
> After this patched offlineimap starts working correctly and writes:
> False
> True
> for every folder.
>
> But synchronisation is broken now. Deleted from remote imap messages
> are not deleted from local maildir, but these messages are not
> restoried to remote imap. It is very bad.
> How to add auto restoring messages to remote imap repository?
>
>
> 2012/12/4 Edward Z. Yang <ezyang at mit.edu>:
>> You might be interested the modified OfflineIMAP algorithm
>> described here: http://blog.ezyang.com/2012/08/how-offlineimap-works/
>> (see the bottom of the post).  A PoC patch is here:
>>
>>     https://github.com/ezyang/offlineimap/commit/266c88f7a1b041ba169e0c0cab767bf412c23672
>>
>> Edward
>>
>> Excerpts from proxym's message of Mon Dec 03 16:02:12 -0800 2012:
>>> No no no...
>>> I don't want to use snapshots/tarbals. I just want bidirectional
>>> append only mode switch in OfflineIMAP and it's config file. Also I
>>> need allowing for editing of Drafts as exception in bidirectional
>>> append mode.
>>>
>>> I already fixed this problem partially. But fix is ugly: I just call cp -al
>>> command to create hard links of all my letters (messages) after
>>> offlineimap finish synchronization. As you know every file already has
>>> counter of hard links to him with value 1. It is in
>>> ext2/ext3/ext4/ntfs file systems.
>>> cp -al just create something which I can name as new "file header" and
>>> increase hard link counter of file. If counter is 0, then no hard
>>> links exists anymore (file is totally removed from file system and
>>> will be rewrited by something else later). So hard links is good
>>> temporary solution for me.
>>> Hard links additional "headers" takes 44M for 1,4G Mail folder in my
>>> ext3 file system now.
>>>
>>> I don't want tarbals. I choosed Maildir format specially, because it
>>> keeps one message by file (actually in raw email format, which is
>>> better). Even in case of file system damage I can restore most of my
>>> messages because of Maildir.
>>>
>>> I know some people, which lost half or even all mail messages, because
>>> Google just cleaned their Gmail mailboxes by unknown reason (support
>>> answered that messages are not restorable). Offlineimap will remove
>>> local copy of messages in this case while next synchronuzation without
>>> any warning. Removing of messages by Google is in TERMS AND CONDITIONS
>>> of Gmail, if you did not know. Same is for any other free Mail server
>>> (maybe for non-free too).
>>>
>>>
>>> Maybe I don't know something about 'readonly' option... I thought it
>>> makes Maildir Mailbox not writable at all and it is not possible to
>>> add new email massages when readonly option is activated... Maybe I am
>>> not right... ?
>>>
>>> Thank you.
>>>
>>> 2012/12/3 Nicolas Sebrecht <nicolas.s-dev at laposte.net>:
>>> > On Sat, Dec 01, 2012 at 05:15:32PM +0300, proxym wrote:
>>> >> Offlineimap does bidirectional synchronization, but it is not smart,
>>> >> it's has not any options to configure behavior for deleting messages.
>>> >>
>>> >> I just want to do bidirectional synchronization without deleting
>>> >> anything ALWAYS. How can I get it with offlineimap?
>>> >
>>> > You need more than OfflineIMAP for what you expect. Coupling OfflineIMAP
>>> > with tarballs/snapshots of the local maildir could do the trick in your
>>> > case.
>>> >
>>> > OfflineIMAP alone can be used as a backup tool ('readonly' option helps
>>> > for the purpose) at the condition that the state of the mailbox is
>>> > _known_ to be correct (so, the sync IS the backup). OfflineIMAP does not
>>> > intend to provide history of backups or anything more advanced.
>>> >
>>> > --
>>> > Nicolas Sebrecht
>>>