Maildir as simultaneous spool and backend.

Maildir as simultaneous spool and backend.

[usenet_spam]

I'm using Gnus v5.11 from cvs'ed emacs 23.  Fetchmail and maildrop
deliver to ~/Maildir like this:

Archives
cur
new
Spam
tmp

The Archives directory contains a bunch of sub-Maildirs:

Commerce
cur
new
Sent
tmp
Ubuntu
(etc.)

I want Gnus to use a single Maildir as both my spool and backend.
Relevant configuration:

(setq mail-sources nil)
(setq gnus-select-method
      `(nnmaildir "localhost"
		  (directory "~/Maildir")
		  (expire-age never)))

All I see in the groups buffer is

       *: nndraft:drafts
       *: nndraft:queue
       *: nnmaildir+localhost:Archives
       *: nnmaildir+localhost:Spam

I don't see my new mail, nor can I find a way to descend into the
Archives directory and see the sub-maildirs within it.  How do I do
that?

Is it okay to use one Maildir as both the 'spool' and 'backend' for
Gnus?  I like to use fetchmail and maildrop to get the mail from my 9
imap and pop accounts into the Maildir, as I like having my mail
local, and can run more than one mail client without worrying about
locking.  I can change around the fetchmail and maildrop configuration
to accomodate gnus, but I'd really rather not have separate spool and
backend Maildirs.

Thanks!

Re: Maildir as simultaneous spool and backend.

[Paul Jarc]

usenet_spam@jfm3.org wrote:
> The Archives directory contains a bunch of sub-Maildirs:

nnmaildir won't scan for sub-maildirs recorsively.  You have to set up
a single directory that contains all your maildirs (or symlinks to
them) at the top level.  Something like this:

mkdir ~/nnmaildir
cd ~/nnmaildir
ln -s ~/Maildir ./
ln -s ~/Maildir/Spam ./
ln -s ~/Maildir/Archives ./
ln -s ~/Maildir/Archives/Commerce ./
ln -s ~/Maildir/Archives/Sent ./
ln -s ~/Maildir/Archives/Ubuntu ./
...

Then use (directory "~/nnmaildir") in your select method.

nnmaildir won't notice or use the hierarchical directory structure,
but if you like hierarchy, you can set up a hierarchical structure in
the Gnus *Group* buffer using topics, no matter how the maildirs are
arranged in the filesystem.

> Is it okay to use one Maildir as both the 'spool' and 'backend' for
> Gnus?

It depends on what you mean by "spool".  It's ok to have outside
programs deliver mail into the maildirs used by nnmaildir.  But if
you're using a maildir as a mail-sources entry, then you can't use
that same maildir as an nnmaildir group.  It's ok to have the
nnmaildir maildirs be subdirectories of the mail-sources maildir, as
long as the full list of nnmaildir maildirs is available in one flat
directory.

> can run more than one mail client without worrying about locking.

I don't recommend running more than one Gnus simultaneously.  Gnus
keeps some state information that isn't stored in the maildirs, or
isn't always kept synchronized with the disk state while it's
running.  Personally, I keep a single Gnus running under screen, and
use screen -x to reconnect to it.


paul

Re: Maildir as simultaneous spool and backend.

[usenet_spam]

On Mar 14, 2:20 pm, p...@po.cwru.edu (Paul Jarc) wrote:
> nnmaildir won't scan for sub-maildirs recorsively.  You have to set up
> a single directory that contains all your maildirs (or symlinks to
> them) at the top level.

Thank you very much!

Is there a reason it doesn't, or is this a feature I can work on?

Re: Maildir as simultaneous spool and backend.

[Michael Widerkrantz]

prj@po.cwru.edu (Paul Jarc) writes:

> I don't recommend running more than one Gnus simultaneously.  Gnus
> keeps some state information that isn't stored in the maildirs, or
> isn't always kept synchronized with the disk state while it's
> running.

You might be interested in using gnus-slave, though. From the manual:

  Each subsequent slave Gnusae should be started with `M-x
  gnus-slave'.  These slaves won't save normal `.newsrc' files, but
  instead save "slave files" that contain information only on what
  groups have been read in the slave session.  When a master Gnus
  starts, it will read (and delete) these slave files, incorporating
  all information from them.  (The slave files will be read in the
  sequence they were created, so the latest changes will have
  precedence.)

> Personally, I keep a single Gnus running under screen, and use
> screen -x to reconnect to it.

Me too for my home Gnus, but I usually use screen -rd.