Gnus development mailing list
 help / color / mirror / Atom feed
From: Sascha Wilde <wilde@sha-bang.de>
To: emacs-devel@gnu.org
Cc: ding <ding@gnus.org>
Subject: Re: Gnus maildir backend issues
Date: Sat, 03 Nov 2007 20:04:55 +0100	[thread overview]
Message-ID: <m2k5ozgnfs.fsf@kenny.sha-bang.de> (raw)
In-Reply-To: <m3sl3obimw.fsf@multivac.cwru.edu> (Paul Jarc's message of "Fri,  02 Nov 2007 14:34:56 -0400")

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

> Sascha Wilde <wilde@sha-bang.de> wrote:
>> 1. the backend creates empty files in .nnmaildir/num for each mail seen
>>    and never deletes them.  This results in thousands and thousands of
>>    (empty) files
>
> Not quite.  There are thousands and thousands of links to a small
> number of empty files (often just one per maildir), so the amount of
> disk space used is very small.

I wasn't worrying about disc space, but a bit about inodes, but as they
are mainly links it turns out my concern wasn't justified.  :)

>>    I don't understand why these files are needed and I definitely
>>    consider it a bug, that they are never removed.
>
> They're used to keep track of article number assignments.  If you
> remove them, you may cause some data corruption.

Hu?  I removed the entire .nnmaildir sometimes and had no problems.
Even more, I wouldn't expect to encounter an problems as I would expect
the original maildir to be self contained.  Actually for most other MUAs
it is, isn't it?

> Is this causing any actual problems for you, or is it an aesthetic
> objection?

Well..  First of all I consider it problematic in general, to store meta
data forever.  Why would one need any information on mails deleted years
ago?  (You might call this "aesthetic".)

The actual problem is:  We are having a bunch of maildir folders on an
nfs volume and sometimes want to do operations like find-greps on all of
them.  In this case all the thousands of files significantly slow down
operations -- or excluding all the .nnmaildir directories makes entering
the commands more cumbersome.  Not a big issue, but annoying.

>>    It would be great to have an option, that says: only move mails to
>>    cur when the folders summary was displayed.
>
> I can see how that might be useful, but it would take a significant
> amount of work.

While it would be very helpful for our current use case (being two, soon
three admins working together on one shared maildir spam folder, me
using gnus and my coworker using mutt), I have to admit, that it
probably isn't worth much afford.

cheers
sascha
-- 
Sascha Wilde : "Ist es nicht schon schlimm genug, dass ICH hier rumtrolle?"
             : (Henning Leise in d.o.c.)

  reply	other threads:[~2007-11-03 19:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-02 15:31 Sascha Wilde
2007-11-02 18:34 ` Paul Jarc
2007-11-03 19:04   ` Sascha Wilde [this message]
2007-11-03 21:19     ` Paul Jarc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2k5ozgnfs.fsf@kenny.sha-bang.de \
    --to=wilde@sha-bang.de \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).