[Dovecot] Deleted email does not appear in the Trash folder
cl at isbd.net
cl at isbd.net
Fri Aug 4 10:56:23 EEST 2006
On Fri, Aug 04, 2006 at 10:12:54AM +1000, Peter Fern wrote:
> cl at isbd.net wrote:
> > There are a number of issues with maildir that eventually make me
> > leave it:-
> >
> > It's not so easy to manually traverse a maildir hierarchy and/or
> > manually search for text in messages. OK, I know there are tools
> > to do it but I often end up writing custom scripts to do things
> > and mbox is just much easier to deal with. (for a start, if using
> > grep, I get a sensible name with mbox, junk with maildir)
> >
> Define 'junk'? And I find that being able to act on each individual
> message as a separate file rather than searching a flat file for keys
> tremendously more flexible, and faster too for that matter.
With your programmers hat on that is possibly true. A 'junk' name is
the maildir naming format of files which is essentially a random
string created to guarantee a unique name. In general a mbox file
name (which is the folder name too) tends to be a meaningful name
given by the user. Thus if I use grep to find a string in a message -
with maildir I get an almost meaningless filename (which I then have
to go and find) whereas with mbox I get the name of the folder.
I *know* that if I write a program which internally searches for stuff
it can use the maildir format much more easily but very often I'm
looking at it from a command line *user* perspective.
> > In mutt at least I get much more meaningful information about
> > maibox size when using mbox than when using maildir.
> >
> Not using mutt, so can't comment... define 'meaningful'?
Well, apart from anything else, I get to see the size of the mbox
folder. With maildir it's significantly more difficult to see how
much space folders are using and mutt (amoong others no doubt) doesn't
show that information for maildir folders.
> > Different MUAs seem to have more trouble working 'cooperatively'
> > when using maildir.
> >
> It appears to be the opposite to me - no need to lock the whole box to
> work with one message... examples?
That's your programmer's hat on again. A *user* doesn't even know
what locking is or means (though will complain about the result of it
not working). What I meant was that if I try and use more than one MUA
(at different times) on the same hierarchy of folders it seems to me
that they're less likely to 'disagree' (and screw each other up) with
mbox than with maildir.
> > This is sort of mixed up with IMAP, but still ....
> > The inconsistent use of '/' and '.' directory (well, pseudo
> > directory) delimiters between different implementations. Who ever
> > thought of using '.' and creating all mailboxes at the same level
> > with longer and longer names should be shot! It makes all sorts
> > of things that expect real directories totally broken.
> >
> You're welcome to change this using namespaces or whatever. I'm curious
> as to what mail tools expect 'real directories'?
>
My head! When I want to move things around in my saved mail hierarchy
it's *far* easier to move real directories. For example if I have
(which I do, approximately) Mail organised as follows:-
~/Mail/archive/oldFriends (a directory)
~/Mail/friends/hospex/fred
~/Mail/friends/hospex/bert
~/Mail/friends/jim
... and I decide that I want to move 'fred' to my oldFriends directory
in the archive area then I can find the file I want by navigating
there (I may not necessarily remember the full name, fred is just an
example) and then mv it to the right place. Similarly I can navigate
to the ~/Mail/friends/hospex directory and then do a grep on all the
mbox files in that directory to search for a particular message.
Both these are sigificantly more awkward if the folders are not in a
real hierarchy.
It's not a *huge* difference, if mbox was unreliable then I'd use
maildir but given that (for me) mbox is reliable using the tools I use
then its advantages are enough for me to prefer mbox.
--
Chris Green (chris at halon.org.uk)
More information about the dovecot
mailing list