Re: OfflineImap 3.0

[dLux <dlux@xxxxxxx>]

1,

To tell the truth I am using my mutt with the following options:

set folder=imap://localhost/INBOX
account-hook imap://localhost/ 'set tunnel="/usr/bin/imapd Maildir"'

So my maildir directory is handled by the Courier Imap daemon. If
I remove a mail, it is removed by the imapd, not mutt directly. I don't
know if it is the same or not.

2,

/--- On Mon, Jul 15, 2002 at 08:49:26AM -0500, John Goerzen wrote:
| I think we can deal with this by trapping the unlink exception, trying to
| re-cache the message list, and if the requested uid no longer occurs in it,
| consider the message already deleted.
| 
| Martijn, mutt has two methods for deleting mail from Maildirs.  If
| maildir_trash is true, it will simply set the flag T for deleted messages,
| never actually unlinking the files.  Otherwise, the default behavior is to
| unlink the files.
| 
| Other mail readers generally seem to choose one of those two strategies,
| with some of them first marking messages T when a user selects the "delete"
| option and then unlinking them when the user changes folders or picks
| "expunge".  This behavior caused a similar error in earlier OfflineIMAP
| versions because it would try to unlink a file that had been renamed to have
| the T flag.
| 
| This problem is a symptom of a wider one, though -- and this is a general
| flaw with Maildirs.  A message can be renamed underneath us at any time (it
| gets marked answered, treashed, or whatnot).  We can try to reduce the
| window for a race to occur but cannot ever completely eliminate it.  Though
| to date I have made no effort to reduce the window -- we can probably make
| it a lot friendlier for people.  I'll loko into that.
\---

I have designed a maildir synchronization software, which is not
finished, and I won't finish it if offlineimap will fits my needs.

My algorithm works the following way (one-way algorithm):

- Generates a file-list in the source directory (it is analogue to your
  IMAP-folder browsing).
- Then compare the mail-list with the stored one and calculate the
  differences. The result will be 3 different list:
  - New files
  - Renamed or moved files
  - Deleted files
- We store the three different transaction list to disk, if the following
  steps fail, we can restart them later.
- We store the filelist which is generated at the first step, this list
  will be used in the next run in the second step.
- Try to copy the new files into the other side. If it fails because the
  source file is not found, then it means that someone renamed or
  deleted the file. We don't care it, because it will be synchronized in
  the next run. If the file already exists in the target place, then we
  don't do copying.
- Try to delete the deleted files in the other side. If it fails, then
  we find a similar email with different flags and remove that (although
  I am not 100% sure that we want to do it). If we can't find the file
  to delete, we ignore it.
- Try to rename the file in the other side too. If it fails, then we
  simply ignore it.
- We remove the transaction list.

This is a ONE-WAY sync, but it can be repeated simply by replacing the
source and the target.

As you can see, the two phases can be completely different. If you do
this algorithm with proper Maildir handling (new files are created in
the "tmp" directory, then moved into the "cur" if it arrived fully).

There is no potential race condition if you do the algorithm like this,
at least it does not cause data loss or improper behaviour.

Regards,

Szabó, Balázs (dLux)
--
== Whip me. Beat me. Make me maintain AIX ==