GNU bug report logs - #36714
27.0.50; Gnus nnmaildir taking long time to recursively visit sub-Maildirs

Previous Next

Full log

Message #55 received at 36714 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 36714 <at> debbugs.gnu.org
Subject: Re: bug#36714: 27.0.50; Gnus nnmaildir taking long time to
 recursively visit sub-Maildirs
Date: Tue, 23 Jul 2019 09:30:01 +0200

* Eric Abrahamsen <eric <at> ericabrahamsen.net> [2019-07-22 19:40]:
> Gnus operates as a general newsreader/email client, not a dedicated
> maildir reader. The maildir functionality needs to fit in with its
> existing paradigms, and right now that means maintaining nov header
> files alongside the messages themselves. Otherwise actually listing
> groups and reading messages would be unbearably slow. I agree it's
> essentially a bug, but it's one that can't be fixed without some
> fundamental alteration of how Gnus works.

Sure, it is general newsreader.

But when acting as email client that reads Maildirs, then just nothing
need to be indexed extra witin maildir folders.

Just because something had to be complex for news, need not be complex
for maildirs.

Reference:
https://en.wikipedia.org/wiki/Maildir

If maildir folders are called groups in Gnus terminology, then listing
them is as simple as detecting if it is a maildir folder.

Without detecting them, wouldb be simple as `ls ~/Maildir`

Maildir has its file structure, it need no program to add something to
it. There are cur, new, tmp sub directories, there is no need for any
additional directories.

> I also don't think this threatens the integrity of the user's files: the
> extra data is maintained in parallel, and doesn't interfere with the
> messages themselves.

I did read nnmaildir info page, and I have not found anything that
would indicate what would Gnus do to my file system. In my case
maildir folders are many, and it makes no difference in speed when
reading it with the `mutt` mail client, but also no difference when
reading it with `maildir` package, but that one is not nicely
developed yet.

It started working on my files for more than 24 hours, and it brought
my system to being not responsive. I did try to leave it running, but
it never ended. So this is real world example.

It created gigabytes of files in those subdirectories without warning
me, without asking me.

That is a programm choice that does not respect the user.

Maildirs could be indexed, but that is left to some external tools

I don't think it should be Gnus responsibility to index them.

In reality, to access maildir is as fast as accessing directory and
files inside. To make index of those files, reading Subject in first
part of file or greping it somehow is enough.

I think that Emacs does have almost everything to read Maildir files
and to use some of mail sending tools. It just needs so little to have
proper Maildir based reading, sorting and sending files.

mu4e package is not good for that, it uses only indexed database, but
not the Maildirs straight.

`maildir` package shows how easy it can be, it is just not yet in best
shape. I can improve it formy own needs, but it would be so nice to
have GNU Emacs become able to replace `mutt`

Jean

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.