home *** CD-ROM | disk | FTP | other *** search
- Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!psuvm!auvm!INNOSOFT.COM!NED
- Errors-to: epmdf@YMIR.BITNET
- X-Envelope-to: PMDF-L@IRLEARN.BITNET
- X-VMS-To: IN%"MITCHELL%UTHSCSA.BITNET@ymir.claremont.edu"
- X-VMS-Cc: IPMDF
- MIME-version: 1.0
- Content-type: TEXT/PLAIN; CHARSET=US-ASCII
- Content-transfer-encoding: 7BIT
- Message-ID: <01GMLUW5M2WY985FZB@YMIR.CLAREMONT.EDU>
- Date: Tue, 21 Jul 92 22:43:19 GMT
- Sender: PMDF Distribution List <PMDF-L@IRLEARN>
- From: Ned Freed <NED@INNOSOFT.COM>
- Subject: RE: VMS MAIL_SERVER and undeleted temp files
- X-To: MITCHELL@UTHSCSA, IPMDF@YMIR
- Newsgroups: bit.listserv.pmdf-l
- Lines: 17
-
- There are two cases where MAIL_SERVER is used. One is with PMDF's incoming
- message processing. The other is with incoming DECnet mail. I suspect that
- the latter is more of an issue; if experience is any indication the use of
- MAIL_SERVER in this way can lead to lots of these files left lying about.
-
- PMDF has no direct involvement; these files are created (and deleted) entirely
- on the whim of MAIL_SERVER. It would seem that a decent exit handler would
- eliminate them unconditionally, but unfortunately this approach is not used
- as far as I know.
-
- In short, this is a problem which, even if some abnormal condition in PMDF
- was the cause (this is totally hypothetical mind you), is totally the
- responsibility of VMS MAIL to clean up properly. Given the fact that these
- are pure scratch files not entered into any directory there is no way for
- PMDF to get a handle on the file even if it wanted to.
-
- Ned
-