Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!CitHex.Caltech.EDU!carl From: carl@CitHex.Caltech.EDU (Carl J Lydick) Newsgroups: comp.os.vms Subject: Re: new mail during compress Message-ID: <871213091343.001@CitHex.Caltech.Edu> Date: 13 Dec 87 17:14:16 GMT References: <8712111649.AA12994@gpu.utcs.toronto.edu> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 57 > I discovered a way of getting your counter out of sync the other direction, > which had more serious consequences. Actually, what you describe below doesn't get your NEWMAILCOUNT out of sync. The counter is there (in SYS$SYSTEM:VMSMAIL.DAT) to keep track of the number of messages you've received but not read. Since you admit to having read the message, the fact that the counter has been decremented means it's working properly. Actually, you need not READ the message to have it counted as no longer new; FILEing it also makes it an old message and decrements the counter. > If you read a new message, decide you want it back in your new mail, but > instead of forwarding it to yourself you just MOVE it to NEWMAIL, things > really get screwed up. It isn't counted as a new message (not surprising > since you have bypassed the normal delivery process), and it won't show up > in a normal read of new mail, either when you first go into MAIL or if you > type READ/NEW. To get at it you have to SELECT NEWMAIL directly. I find > this strange since I wouldn't have thought the number of new messages would > have any idea *which* messages were actually new. You're right; the counter DOESN'T know which messages are or are not new. That's why it can get out of sync. > Evidently being in NEWMAIL is not the only criterion for being considered > new MAIL. In order for a message to qualify as new, it must satisfy two criteria: 1) It must be in the NEWMAIL folder in the file MAIL.MAI in your mail directory (this is the condition you knew about); and 2) The low-order bit of the 49th byte in the header record for that message must be set. If it weren't for the extra condition imposed on new messages, there wouldn't be much point in the SELECT/NEW and READ/NEW, since the "SELECT NEWMAIL" or "READ NEWMAIL" would provide the same functionality, except for their side effect of reconciling the NEWMAILCOUNT with the actual number of new messages. > It doesn't matter what the date on the message is; you can have both older > and newer ones in the folder, and the one that was MOVEd there will not > show up. So it isn't simply a case of only displaying the number of > messages the counter knows about. Here again, the second criterion comes into play. Since the message you MOVEd has the `new' bit cleared, the /NEW commands ignore it. > Does anyone have an explanation for this behaviour? Are there actually > *two* NEWMAIL folders, the one you put the message in and the one with real > new MAIL in it? I seem to recall, though, that after doing a SELECT > NEWMAIL the real new messages showed up as well No, there can only be one folder with a given name in any mail file. The folders are implemented by reserving a field in the header record of the message in which the name of the folder to which the message belongs is stored. This field is associated with key 1 in the indexed file (key 0 is the date and time the message arrived). Given this implementation, if two folders in the same file have the same name, they are by definition the same folder.