From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/11043 Path: main.gmane.org!not-for-mail From: Sudish Joseph Newsgroups: gmane.emacs.gnus.general Subject: Re: saving to nnml groups Date: 23 May 1997 10:26:02 -0400 Message-ID: References: <873eresl3p.fsf@perv.daft.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1035150818 27942 80.91.224.250 (20 Oct 2002 21:53:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:53:38 +0000 (UTC) Return-Path: Original-Received: from sandy.calag.com (root@sandy [206.190.83.128]) by altair.xemacs.org (8.8.5/8.8.5) with ESMTP id IAA14289 for ; Fri, 23 May 1997 08:39:42 -0700 Original-Received: from xemacs.org (xemacs.cs.uiuc.edu [128.174.252.16]) by sandy.calag.com (8.8.5/8.8.5) with ESMTP id IAA31265 for ; Fri, 23 May 1997 08:39:25 -0700 Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by xemacs.org (8.8.5/8.8.5) with SMTP id KAA13228 for ; Fri, 23 May 1997 10:38:43 -0500 (CDT) Original-Received: from atreides.eng.mindspring.net (atreides.eng.mindspring.net [207.69.183.11]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id for ; Fri, 23 May 1997 16:26:33 +0200 Original-Received: (qmail 32495 invoked by uid 52477); 23 May 1997 14:26:02 -0000 Original-To: ding@ifi.uio.no In-Reply-To: Kai Grossjohann's message of 23 May 1997 10:01:31 +0200 X-Mailer: Gnus v5.4.52/XEmacs 20.2 Original-Lines: 83 Original-Xref: altair.xemacs.org dgnus-list:1431 Xref: main.gmane.org gmane.emacs.gnus.general:11043 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:11043 Kai Grossjohann writes: > Been there, done that. Worked like a charm. But now I use > nnmail-split and don't think it's slow at all (for 50 to 100 mails in > the morning). IMHO, it depends on the speed of the filesystem you're writing to. At school, splitting over NFS was unbearably slow, so I did use direct asynch delivery to nnml folders (this was before gnus-demon was around, though). These days, I'm lucky enough to be using a local ext2 filesystem with Linux. This is much, much, much better, but it can still be slow if you've got 100's of messages. However, setting up up a gnus-daemon handler to auto-split mail every 10 mins or so ensures that I never have a huge number of messages to be split at any given time. Definitely the way to go if you can leave your Emacs up for days. To go back to the original question, expiration isn't the only time when files in your nnml folders get manipulated by Gnus. Splitting also clobbers the overview file and articles -- in general, it is a very bad idea to combine asynch delivery and Gnus splitting. Use the latter, asynch delivery is unsupported and needs you to use the programming skills you mentioned. :> Even if you don't use Gnus splitting at all, you still have to be careful with the `B' commands. Moving an article into a group with `B m' can actually lose mail -- Gnus doesn't re-read the overview file or the active file before such commands, so an asynch-delivered article can get clobbered -- which is a lot worse than nov file corruption. If you're willing to forgo `B m's into asynch groups and Gnus splitting, you can get away with asynch delivery -- with some work. You'll need to write a script or two to walk your nnml tree and compare the output of readdir(3) with the overview file. Two kinds of problems to look for: missing nov entries (easy enough to regenerate), and out of order nov entries (these won't be a problem with mailagent, since it serializes all delivery, but is definitely a problem with procmail). (Lars refused to slow down overview file parsing by handling the latter correctly in Gnus -- probably just as well, since then people may assume that asynch delivery is supported. :/) I used to have such a script, but don't seem to have retained it after leaving school. There's a pbiff program I wrote for Perl/Tk (whatever beta was current in mid 95, so the Tk part is guaranteed to be broken today) that already walks the nnml tree -- it used to be stored somewhere on Lars's site. It's the same thing I modified for checking the tree, might offer you a start if you plan to walk down this lonely, unsupported, deprecated, warned-against road. :) Last, and certainly the least, there's the active file. It'll get corrupted (in the sense of missing new entries) too. This is self correcting, though, since the next message for that group will fix the problem. It's easy to look for this problem from an external script. This issue was discussed in great detail in late '95, you might wish to consult the archives. My opinion is that splitting to separate spool files is entirely useless for anything other than the purpose of biffing. It doesn't give you any speedups (a minor slowdown actually, depending on your filesystem), and just complicates things. If you aren't into biffing, avoid the nnml-.*-procmail stuff entirely. (It does give you a little more parallelism with procmail, but that doesn't translate to any speedup when you hit `g'). Someone's going to say that procmail/mailagent can do fancier stuff than Gnus' in this regard. Sure, but how many actually do such things? Even if you do, IMHO, it's better to simply add a header to the message in the external filter and split on that header in Gnus. As for biffing, IMHO, a neato-keen way to do it with one spool file is to modify from(1) to read the split-fancy variable and emulate Gnus' split to tell you where messages would go or to just show you messages that go to a particular folder, etc. The from(1) I use is written in perl and I would've done this if parsing balanced expressions wasn't such an annoyance with perl. Emacs' read functions are so cool for this kind of thing. Hmm, maybe have Gnus write out a version that's easy for from(1) to parse? -Sudish