Brock Rozen wrote,
R> On Fri, 15 Aug 1997, David W. Tamkin wrote:
Actually, I didn't write what followed; Karl Vogel did:
V> cat - backup > backup.$$ && mv backup.$$ backup
V> You'll get some savings from mv not having to copy the file...
I wrote this:
T> Very good point, Karl. My reasoning in suggesting /tmp/backup.$$ is that
T> one might be so near one's storage quota that $MAILDIR/backup.$$ couldn't be
T> written out in full ...
Brock has now responded,
R> Well, considering I'm one of the sysadmins, the quota isn't an issue for
R> me. Any other better way to do it w/o worrying about quota?
Pretty much no to the extent of my knowledge, but that isn't much.
R> Any other time savers though?
Probably not; Unix's design makes it easy to append text to the end of an
existing file but not so easy to insert text at the top of one.
T> Besides, when I posted I was deprecating the idea
T> of adding gyrations for every incoming message instead of adding them just
T> once a day in Brock's cron job.
R> There's a good reasoning behind it though -- if you want to see a message
R> that you erased five minutes earlier, it's all in one file.
Again, there are trade-offs between the two arrangements: adding new messages
at the end of the backup folder is less work with each arriving message but
more for the cron job, while inserting new messages at the top of the backup
folder is more work for procmail with each arrival but less for the cron job.
But if you personally consult the backup folder with your own eyes, you're
going to have a preference for having new messages at the top or for having
them at the end, and the human factor tips the balance.