* Found no mail! [sgnus 0.17] @ 1995-12-03 5:22 Steven L. Baur 1995-12-03 7:29 ` Steven L. Baur 1995-12-04 16:26 ` General sgnus 0.17 problems [Was: Found no mail! [sgnus 0.17]] Sten Drescher 0 siblings, 2 replies; 9+ messages in thread From: Steven L. Baur @ 1995-12-03 5:22 UTC (permalink / raw) Take great precautions before trusting your mail to 0.17. There looks like there might be a problem in nnmail.el. -- steve@miranova.com baur ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Found no mail! [sgnus 0.17] 1995-12-03 5:22 Found no mail! [sgnus 0.17] Steven L. Baur @ 1995-12-03 7:29 ` Steven L. Baur 1995-12-03 22:25 ` Erik Selberg 1995-12-04 1:50 ` Found no mail! [sgnus 0.17] Lars Magne Ingebrigtsen 1995-12-04 16:26 ` General sgnus 0.17 problems [Was: Found no mail! [sgnus 0.17]] Sten Drescher 1 sibling, 2 replies; 9+ messages in thread From: Steven L. Baur @ 1995-12-03 7:29 UTC (permalink / raw) It's not a Gnus problem. The ``fix'' applies to any late model Emacs. If you don't set mail-use-rfc822 to t, and try to save an article with a From line that looks something like: From: joeluser@aol.com (Joe "Stupid" Luser) The Emacs mail utilies will, when saving to mailbox format, convert it into a From_ line that looks like: >From joeluser@aol.com (JoeLuser) ... Which will cause Gnus to bomb when attempting to deal with it later (as in nnmail-process-unix-mail-format putting it into an nnml group) since it does not match the ugly rmail-unix-mail-delimiter regular expression. This applies to anything in Emacs calling the standard mail-utils to save in mailbox format. Regards, -- steve@miranova.com baur ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Found no mail! [sgnus 0.17] 1995-12-03 7:29 ` Steven L. Baur @ 1995-12-03 22:25 ` Erik Selberg [not found] ` <m2ivjxllq9.fsf@diana.miranova.com> 1995-12-04 1:50 ` Found no mail! [sgnus 0.17] Lars Magne Ingebrigtsen 1 sibling, 1 reply; 9+ messages in thread From: Erik Selberg @ 1995-12-03 22:25 UTC (permalink / raw) > It's not a Gnus problem. The ``fix'' applies to any late model Emacs. > If you don't set mail-use-rfc822 to t, and try to save an article with > a From line that looks something like: I'm still getting it. Here are symptoms: upon clean startup, things work fine. "Found no mail!" appears upon subsequet calls to gnus-group-get-new-news. I believe this to be the case due to a .gnus-crash-box file which is generated and empty. Apparently, gnus believes that this contains the contents of a spool file (seems that it's trying to read it). "Found no mail!" also appears if the spool file exists, but is zero-length, a common occurance around here (as spool files are symlinked). -Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <m2ivjxllq9.fsf@diana.miranova.com>]
[parent not found: <199512040241.SAA20522@meitner.cs.washington.edu>]
[parent not found: <m2bupo39qu.fsf@diana.miranova.com>]
* Re: Found no mail! [sgnus 0.17] [not found] ` <m2bupo39qu.fsf@diana.miranova.com> @ 1995-12-04 20:06 ` Erik Selberg 1995-12-04 21:09 ` Symbolic Links for mailboxes in Gnus Steven L. Baur 0 siblings, 1 reply; 9+ messages in thread From: Erik Selberg @ 1995-12-04 20:06 UTC (permalink / raw) Cc: ding Steven L Baur writes: > The patch you posted to the list solves the wrong problem too late. > Having a zero length file in nnmail-process-unix-mail-format means > that nnmail-prepare-incoming-hook has already been called on it *and* > the prior zero-length checks have been botched. I don't know about prior zero-length hooks, but my nnmail-prepare-incoming-hook is nil. Perhaps there's a problem? > I do see a problem with symbolic links to spool files. I have been > unable to make that [mis]feature work at all. Eg. a symbolic link to > either a zero length file, or to a file containing valid mail is > missed in the spool scan *and* a specific M-g scan. This behavior is > identical under both XEmacs 19.13 and Emacs 19.30. curious; my spool file is a symbolic link. Perhaps ding is not reading it as such? > The question is why do they work/bomb for you at all? > The first place to look is ange FTP, since it has weird hooks into all > the file checks. > What version of ange FTP are you using? You should be using the > version supplied with Emacs. Check every directory in your load-path > to be sure. > Are you using file names with colons in them? I'm using standard emacs 19.30; I took ange-ftp out of my local libs when 19 was available on our system. No colons or nuthin either. -Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Symbolic Links for mailboxes in Gnus 1995-12-04 20:06 ` Erik Selberg @ 1995-12-04 21:09 ` Steven L. Baur 1995-12-04 23:47 ` Erik Selberg 0 siblings, 1 reply; 9+ messages in thread From: Steven L. Baur @ 1995-12-04 21:09 UTC (permalink / raw) Cc: ding (Code examples taken from nnmail.el) 1) If you're using procmail for mail splitting, symbolic links in the procmail directory are automagically removed from consideration by the following code in nnmail-get-spool-files: ;; Remove any directories that inadvertantly match the procmail ;; suffix, which might happen if the suffix is "". (while p (and (or (file-directory-p (car p)) >>>> (file-symlink-p (car p))) (setq procmails (delete (car p) procmails))) (setq p (cdr p))) This is as it should be, IMHO. However, the incorrect comment should be changed to reflect the fact that symbolic links are ditched too. 2) If you are not using procmail, the the following code loses when the mailbox is a symbolic link (from nnmail-get-new-mail): ;; The we go through all the existing spool files and split the ;; mail from each. (while spools (setq spool (pop spools)) ;; We read each spool file if either the spool is a POP-mail ;; spool, or the file exists. We can't check for the ;; existance of POPped mail. (when (or (string-match "^po:" spool) (and (file-exists-p spool) >>>> (> (nth 7 (file-attributes spool)) 0))) The idiom (nth 7 (file-attributes ...)) returns the file size, but with a symbolic link, it will return the length in characters of the filename the link is pointing to (always > 0). In order to make this code work with symbolic links it must be changed to: (> (nth 7 (file-attributes (file-truename spool))) 0))) Now the code will work with symbolic links, which also seem to not bother movemail. Do we really want Gnus to encourage this unsafe practice? -- steve@miranova.com baur ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Symbolic Links for mailboxes in Gnus 1995-12-04 21:09 ` Symbolic Links for mailboxes in Gnus Steven L. Baur @ 1995-12-04 23:47 ` Erik Selberg 0 siblings, 0 replies; 9+ messages in thread From: Erik Selberg @ 1995-12-04 23:47 UTC (permalink / raw) Cc: ding Steven L Baur writes: > 2) If you are not using procmail, the the following code loses when > the mailbox is a symbolic link (from nnmail-get-new-mail): > ;; The we go through all the existing spool files and split the > ;; mail from each. > (while spools > (setq spool (pop spools)) > ;; We read each spool file if either the spool is a POP-mail > ;; spool, or the file exists. We can't check for the > ;; existance of POPped mail. > (when (or (string-match "^po:" spool) > (and (file-exists-p spool) >>>>> (> (nth 7 (file-attributes spool)) 0))) > The idiom (nth 7 (file-attributes ...)) returns the file size, but > with a symbolic link, it will return the length in characters of the > filename the link is pointing to (always > 0). > In order to make this code work with symbolic links it must be changed to: > (> (nth 7 (file-attributes (file-truename spool))) 0))) > Now the code will work with symbolic links, which also seem to not > bother movemail. yup... just tried it, and things are working well without the patch I previously posted. > Do we really want Gnus to encourage this unsafe practice? I misunderstand how this can be termed "unsafe." Could you elaborate? Here at UW, it's nearly a necessity because of our completely outdated spool system. -Erik ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Found no mail! [sgnus 0.17] 1995-12-03 7:29 ` Steven L. Baur 1995-12-03 22:25 ` Erik Selberg @ 1995-12-04 1:50 ` Lars Magne Ingebrigtsen 1995-12-04 3:52 ` Steven L. Baur 1 sibling, 1 reply; 9+ messages in thread From: Lars Magne Ingebrigtsen @ 1995-12-04 1:50 UTC (permalink / raw) steve@miranova.com (Steven L. Baur) writes: > If you don't set mail-use-rfc822 to t, and try to save an article with > a From line that looks something like: > > From: joeluser@aol.com (Joe "Stupid" Luser) > > The Emacs mail utilies will, when saving to mailbox format, convert it > into a From_ line that looks like: > > >From joeluser@aol.com (JoeLuser) ... How odd. But when does Gnus use functions that have this... interesting (yuck) feature? And... why does this happen? The documentation to that variable doesn't say anything specific about when it's used: mail-use-rfc822's value is nil Documentation: *If non-nil, use a full, hairy RFC822 parser on mail addresses. Otherwise, (the default) use a smaller, somewhat faster, and often correct parser. -- Home is where the cat is. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Found no mail! [sgnus 0.17] 1995-12-04 1:50 ` Found no mail! [sgnus 0.17] Lars Magne Ingebrigtsen @ 1995-12-04 3:52 ` Steven L. Baur 0 siblings, 0 replies; 9+ messages in thread From: Steven L. Baur @ 1995-12-04 3:52 UTC (permalink / raw) >>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes: Lars> steve@miranova.com (Steven L. Baur) writes: >> If you don't set mail-use-rfc822 to t ...(Emacs can barf) Lars> How odd. But when does Gnus use functions that have this... Lars> interesting (yuck) feature? The one that bit me was gnus-summary-save-in-mail, but anything which calls rmail-output. The only other function I see doing it is gnus-author-copy-saver. Lars> And... why does this happen? As near as I can tell it strips exactly one level of quotes out at the most nested level. This works quite well unless someone is taking full advantage of RFC822 syntax ... Lars> The documentation to that variable doesn't say anything Lars> specific about when it's used: I just did a grep on mail-use-rfc822 in the emacs lisp directories, and I've changed my mind. It is a Gnus bug. The variable itself is only read in mail-utils.el, in the function mail-strip-quoted-names, which is used to build From_ lines. It is set to t temporarily in rmail.el in rmail-make-in-reply-to-field. It is also set to t in a pair of (let)s in vm-reply.el and vm-summary.el. [From vm-reply.el] (let ((mail-use-rfc822 t)) (and to (setq to (mail-strip-quoted-names to))) (and cc (setq cc (mail-strip-quoted-names cc))))) I think you *should* protect all calls to rmail-output in gnus in the same fashion. (Patch appended). Lars> mail-use-rfc822's value is nil Lars> Documentation: *If non-nil, use a full, hairy RFC822 parser Lars> on mail addresses. Otherwise, (the default) use a smaller, Lars> somewhat faster, and often correct parser. It works exactly as advertised. I vote for correctness since the consequences are so unpleasant. Patch follows: =================================================================== RCS file: RCS/ChangeLog,v retrieving revision 1.8 diff -u -r1.8 ChangeLog --- 1.8 1995/12/03 20:10:13 +++ ChangeLog 1995/12/04 03:42:21 @@ -1,5 +1,10 @@ Sun Dec 3 11:44:08 1995 Steven L. Baur <steve@miranova.com> + * gnus-msg.el (gnus-inews-do-fcc): Protect call to rmail-output by + temporarily setting mail-use-rfc822 to t. + + * gnus.el (gnus-summary-save-in-mail): Ditto. + * gnus.el (gnus-slave-no-server): New Function. (gnus-no-server): Add optional slave parameter. =================================================================== RCS file: RCS/gnus.el,v retrieving revision 1.9 diff -u -r1.9 gnus.el --- 1.9 1995/12/03 20:44:46 +++ gnus.el 1995/12/04 03:41:34 @@ -11670,7 +11670,8 @@ (widen) (if (and (file-readable-p filename) (mail-file-babyl-p filename)) (gnus-output-to-rmail filename) - (rmail-output filename 1 t t))))) + (let ((mail-use-rfc822 t)) + (rmail-output filename 1 t t)))))) ;; Remember the directory name to save articles. (setq gnus-newsgroup-last-mail filename))) =================================================================== RCS file: RCS/gnus-msg.el,v retrieving revision 1.6 diff -u -r1.6 gnus-msg.el --- 1.6 1995/12/04 03:37:10 +++ gnus-msg.el 1995/12/04 03:39:19 @@ -1286,7 +1286,8 @@ (funcall gnus-author-copy-saver file) (if (and (file-readable-p file) (mail-file-babyl-p file)) (gnus-output-to-rmail file) - (rmail-output file 1 t t))))))))) + (let ((mail-use-rfc822 t)) + (rmail-output file 1 t t)))))))))) (defun gnus-inews-path () "Return uucp path." -- steve@miranova.com baur ^ permalink raw reply [flat|nested] 9+ messages in thread
* General sgnus 0.17 problems [Was: Found no mail! [sgnus 0.17]] 1995-12-03 5:22 Found no mail! [sgnus 0.17] Steven L. Baur 1995-12-03 7:29 ` Steven L. Baur @ 1995-12-04 16:26 ` Sten Drescher 1 sibling, 0 replies; 9+ messages in thread From: Sten Drescher @ 1995-12-04 16:26 UTC (permalink / raw) steve@miranova.com (Steven L. Baur) said: SLB> Take great precautions before trusting your mail to 0.17. There SLB> looks like there might be a problem in nnmail.el. Looks like there might be lots of problems. Finding the best unread group doesn't work in the Groups buffer (it goes to the end of the buffer) or the Summary buffer (it returns to the Group buffer instead), reading the next article in the thread doesn't work in the summary buffer (it goes to the first unread article in the buffer), ... -- #include <disclaimer.h> /* Sten Drescher */ To get my PGP public key, send me email with your public key and Subject: PGP key exchange Key fingerprint = 90 5F 1D FD A6 7C 84 5E A9 D3 90 16 B2 44 C4 F3 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1995-12-04 23:47 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-12-03 5:22 Found no mail! [sgnus 0.17] Steven L. Baur 1995-12-03 7:29 ` Steven L. Baur 1995-12-03 22:25 ` Erik Selberg [not found] ` <m2ivjxllq9.fsf@diana.miranova.com> [not found] ` <199512040241.SAA20522@meitner.cs.washington.edu> [not found] ` <m2bupo39qu.fsf@diana.miranova.com> 1995-12-04 20:06 ` Erik Selberg 1995-12-04 21:09 ` Symbolic Links for mailboxes in Gnus Steven L. Baur 1995-12-04 23:47 ` Erik Selberg 1995-12-04 1:50 ` Found no mail! [sgnus 0.17] Lars Magne Ingebrigtsen 1995-12-04 3:52 ` Steven L. Baur 1995-12-04 16:26 ` General sgnus 0.17 problems [Was: Found no mail! [sgnus 0.17]] Sten Drescher
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).