Symbolic Links for mailboxes in Gnus

[steve@miranova.com (Steven L. Baur)]

(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