[kdepim-users] adding maildir files

[Ingo Klöcker]

On Wednesday 04 May 2016 21:24:01 Johann Rohwer wrote:
> It seems the maildir implementation is different in akonadi as
> compared to dovecot (and standard maildir). Consider a mail folder
> structure:
> fol1/fol2/fol3
> 
> When creating this in kmail under local folders (i.e. a local akonadi
> maildir resource), the directory structure on disk is as follows:
> fol1/{cur|new|tmp}
> .fol1.directory/fol2/{cur|new|tmp}
> .fol1.directory/.fol2.directory/fol3/{cur|new|tmp}
> 
> In dovecot (and standard maildir) the directory structure is as
> follows: .fol1/{cur|new|tmp}
> .fol1.fol2/{cur|new|tmp}
> .fol1.fol2.fol3/{cur|new|tmp}

To be precise, this is not standard maildir (because standard maildir 
only defines the on disk representation of single folders; see 
https://cr.yp.to/proto/maildir.html), but Maildir++ (http://www.courier-mta.org/imap/README.maildirquota.html).

 
> There is no nested directory structure on disk and mail (sub)folders
> are indicated by a dot in the filename. I have noticed this before
> and it is an incompatibility that prevents simple copying from a
> dovecot server to a local akonadi maildir resource. Anyone know the
> reason for this difference? The dovecot implementation seems cleaner.

The reason is simple: Almost 20 years ago, when support for subfolders 
was added to KMail that's what the developers came up with. Back then 
Maildir++ probably hadn't been "invented" yet. (The Wikipedia article on 
Maildir reads "Varshavchik, Sam (1998) Maildir++ and Maildir quotas 
which has the Maildir++ specification buried within it".)

Why was this never changed?
Reason 1: Backwards compatibility (aka inertia ;-))
Reason 2: There never was a compelling enough reason for changing it.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20160504/5f341cfe/attachment.sig>