Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!ATHENA.MIT.EDU!wdc From: wdc@ATHENA.MIT.EDU (Bill Cattey) Newsgroups: comp.soft-sys.andrew Subject: Re: Some REAL confessions about AMS speed Message-ID: Date: 13 Jul 90 22:35:23 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 My recollection of the problem with getting stuff from /usr/spool/mail was that we now understood what it all was: AMS reads from the begining of the spool file, and takes all the newer messages. Then it truncates /usr/spool/mail file. The mail that went down the black hole was any mail that the user put back in the /usr/spool/mail file from previous interactions with mailers that allowed that to be done. That mail was not taken by AMS because it was old, and was not saved away, because AMS ostensibly truncated the file without looking at all of it. The solution was to make AMS not take input from /usr/spool/mail if it noticed that the hold flag was set in either the person's local or system wide mail configuration file. As a side note, a couple of new AMS users are confused when they get the error message complaining about this condition. We've been telling them to clear the hold bit. I think we may occasionally forget to mention to them that mail put back in /usr/spool will be lost if you use AMS on it. (Some history just seems to fall through the cracks... :-) ) I always felt that AMS should have been made smarter to actually understand what all it was doing to the spool file, but I didn't say anything at the time, because I didn't want to ask for work on adding hair to a subsystem that didn't affect me directly. -wdc