sgnus-0.29, automatic archiving of outoing mail

sgnus-0.29, automatic archiving of outoing mail

[Kai Grossjohann]

Whenever sgnus gets new news, I see the following two messages:

    Reading active file from outgoing via nnfolder...
    Cannot read active file from nnfolder server.

This is most probably because gnus-message-archive-method is 

    (nnfolder "outgoing"
              (nnfolder-directory "~/Mail/outgoing/")
              (nnfolder-active-file "~/Mail/outgoing/active")
              (nnfolder-get-new-mail nil)
              (nnfolder-inhibit-expiry t))

This also happens if I don't change the default value which has
archive instead of outgoing.  What can I do to solve the problem?
Setting the above variable to nil doesn't quite cut it.  (NB
gnus-message-archive-group is nil.)

tia,
        kai
--
Life is hard and then you die.

Re: sgnus-0.29, automatic archiving of outoing mail

[d. hall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

ð thus on 19 Jan 1996 16:15:58 +0100, Kai virtually scripted...

Kai>     Reading active file from outgoing via nnfolder...
kai>     Cannot read active file from nnfolder server.

Kai> This is most probably because gnus-message-archive-method is

Kai>     (nnfolder "outgoing"
Kai>               (nnfolder-directory "~/Mail/outgoing/")
Kai>               (nnfolder-active-file "~/Mail/outgoing/active")
Kai>               (nnfolder-get-new-mail nil)
Kai>               (nnfolder-inhibit-expiry t))

The method I've used so far since I used personalized nnfolder-directory
variables (setq nnfolder-directory "~/.mailbox/") also I want the active
file to be the same is just setting

(setq gnus-message-archive-method
      '(nnfolder
        ""
        (nnfolder-directory             "~/.mailbox/")
        (nnfolder-active-file           "~/.mailbox/active")
        (nnfolder-get-new-mail           nil)
        (nnfolder-inhibit-expiry         t)))

It was disturbing to have the archive method supercede all the variables I
had set up.  It also took me 2 hours to fiddle with it until I finally gave
up and stuck all the archive nnfolder stuff with my usual nnfolder files.

Also, and this may be a personal problem with emacs in general, since I've
encountered it twice on both a SunOS and Linux platforms.  FSF Emacs
19.30.1 emacs seems to want to create "no permission" files when creating a
process.  I'm still trying to figure out as to what is wrong, and I haven't
found any pertinent Emacs patches at prep.  Any suggestions on where to
look (either it be Emacs-lisp or C source).  I haven't foggiest as to why
I'm getting these files.

On a side note... can anybody see any problems with the current setup as
far as locking mail files?  Since my mail spool can be read either online
or via pop3, I don't have procmail separate into spool files, but use
formail to append a X-Folder: header line to each email.

:0 H
* ^TOzsh.*@math.gatech.edu
| formail -A"X-Folder: zshell" >> $DEFAULT

:0 H
* ^TOlist@illusion.apk.net
| formail -A"X-Folder: source" >> $DEFAULT

Like so.  Since way the spool file stays consistant.  Then I use:

(setq nnmail-split-methods
      '(("mail.zshell" "^X-Folder: zshell")
	("mail.source" "^X-Folder: source")))

The only problem I forsee is that appending might cause corruption if two
concurrent appends occur at the same time.  I'm not proficient enough in
procmail's internals to know if each procmail process locks for the
completion of the pipe.

d.
- --
<<If you're so perfect, try walking on water.>>
				~ anonymous scriptor

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMQCfL4X26urqpgG1AQFG4gQAqNvWufUGISloXoDE0SEgwEzz71RAML1N
CqHcNalehiJ/QcSrbcCzzy5tZB+toVhXJT0spnm7hfNcJ0TucOdGy4/pOJ2MmxVB
sIkqmXW6a35Bn/oZ6eag+6lnVXv743U/MgFLUTtByYSV55xfxCH/AO/ZJSTQ9AyJ
KUlL9ia8KRI=
=ksuZ
-----END PGP SIGNATURE-----

Re: sgnus-0.29, automatic archiving of outoing mail

[Greg Stark]

I've CC'd bug-gnu-emacs though this doesn't constitute a bug report.
Hopefully someone there will know what's up with this, or will be able
to suggest some way we can reproduce the bug and help track it down.

> Also, and this may be a personal problem with emacs in general, since I've
> encountered it twice on both a SunOS and Linux platforms.  FSF Emacs
> 19.30.1 emacs seems to want to create "no permission" files when creating a
> process.  I'm still trying to figure out as to what is wrong, and I haven't
> found any pertinent Emacs patches at prep.  Any suggestions on where to
> look (either it be Emacs-lisp or C source).  I haven't foggiest as to why
> I'm getting these files.

I've seen this "no permission" bug too, where my mail files showed up with
mode 000. It was the strangest thing since it only happened once, and hasn't
reappeared. I've never seen Emacs do that before, at least not before 19.30.

I'm using FSF Emacs 19.30 on a Dec Ultrix machine using AFS, 
so it doesn't look like it's operating system or file system specific.
There's no reference in nnmail.el to any of the *-file-modes functions
(possibly a bug:) so it has to be a strange new Emacs bug.
Possibly the default-file-modes is being scoped weirdly so that some
process-filter is affecting the behaviour, but I don't see how.

greg

Re: sgnus-0.29, automatic archiving of outoing mail

[Lars Magne Ingebrigtsen]

"d. hall" <dhall@apk.net> writes:

> The method I've used so far since I used personalized nnfolder-directory
> variables (setq nnfolder-directory "~/.mailbox/") also I want the active
> file to be the same is just setting
> 
> (setq gnus-message-archive-method
>       '(nnfolder
>         ""
>         (nnfolder-directory             "~/.mailbox/")
>         (nnfolder-active-file           "~/.mailbox/active")
>         (nnfolder-get-new-mail           nil)
>         (nnfolder-inhibit-expiry         t)))
> 
> It was disturbing to have the archive method supercede all the variables I
> had set up.  

That was why the nnfolder virtual server was called "archive" to avoid
clobbering the user variables people use when reading from their
"normal" nnfolder groups.  So things should work if you rename it back
to "archive".

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."