From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 18-APR-1994 08:54:35.74
To:	EVERHART
CC:	
Subj:	RE: Global MAIL compress for all users?

Message-Id: <9404162336.AA24773@uu3.psi.com>
Date: Sat, 16 Apr 94 19:35:15 EDT
From: Jerry Leichter <leichter@lrw.com>
To: INFO-VAX@SRI.COM
Subject: RE: Global MAIL compress for all users?
X-Vms-Mail-To: UUCP%"DAVIS@BELMONT.EDU"

	Many (most) of our users never get around to doing COMPRESS on their
	mail file.  Even after they're told they need to do it periodically.
	(a) Is there a way to force a MAIL/COMPRESS on another user's account,
	and then delete the resulting MAIL.OLD file?  Or is this restricted to
	being done personally by each user?  (b) If there is such a procedure,
	can it be done globally for all VAX users?  Clean up the whole mail
	system at once...

No, neither of these things exist - with good reason!

1.  If your users aren't PURGE'ing their mail - either through having
AUTOPURGE set or by typing PURGE regularly - COMPRESS will do *absolutely
nothing*, since it only recovers space that's actually been deleted.

2.  If there are more than 32767 deleted bytes, MAIL will do an automatic
PURGE/RECLAIM when it completes the PURGE.  The reclaimed space will be
re-used for new mail.

3.  If a user receives and deletes mail at a more-or-less constant rate, the
only difference between the PURGE/RECLAIM case and the COMPRESS case is that,
in the latter, the file will shrink, only to grow back to its former size by
roughly the time the next PURGE/RECLAIM would be due.  In the former case,
the file remains at the same larger size, and space within it is re-used.

4.  It is true that, should a user's mail usage see a spike - for example, if
the user is away for a while and builds up a large backlog, and later reads
and deletes stuff back to its "steady-state" level - then in the PURGE/RECLAIM
case the mail file will remain at its peak size.  However, this by its nature
is a relatively situation.

So, in practice, there usually isn't all *that* much to gain.

5.  COMPRESS leaves behind a MAIL.OLD file.  If you leave it to your users
to delete it, they won't - and you'll soon be wasting more space on dead
MAIL.OLD files than you ever were on uncompressed MAIL.MAI files.

6.  So, you say, why not just delete the MAIL.OLD file for the user?  *Because
this can lead to loss of mail*!  Mail arriving for a user while a COMPRESS is
running will usually end up in the MAIL.OLD file *only*, with no copy in the
new MAIL.MAI file.

Personally, I've always considered this a bug in mail:  It should prevent
any receipt of mail during the compression, or alternatively detect that
this has happened and either move the newly-arrived mail automatically, or
(easier but less desireable) cancel the compression and retain the old file.

However, MAIL does neither.  Instead, it relies on the assumption that a user
will do a COMPRESS interactively, notice any new mail messages, and remember
to check folder NEWMAIL in MAIL.OLD for those messages.  (How many users
actually know this?  How many never use COMPRESS because they've been warned
off by someone who heard about someone who lost mail because of this old, old
bug?)

In any case:  COMPRESS'ing user's mail files can do them damage.  I would be
quite upset if I discovered my system manager was doing this.  If I actually
lost mail because of it - and statistically it *will* happen eventually - I'd
see to it the system manager paid for his error.
							-- Jerry