Hello Roy!

02 Aug 04 04:07, Roy J. Tellason wrote to Mike Tripp:

 MT>> The new version was only growing to swallow the new messages
 MT>> being appended, so there's no reason for them to be occupying
 MT>> more than the actual number of bytes required to do so.

 RT> Yup.  And the way things looked it wasn't ever gonna get any smaller.
 RT> I'm looking at something like 38M currently on that drive,  not so
 RT> much that I need to worry about an 8M file eating too much space but
 RT> still...

I was referring to your new replacement files here, not the original hosed
version.  If you don't assign it any purge paramaters either, then there's
no reason for SQPACK to ever shrink the file, and it should head straight
back for 8mb or however far it grows until it a data integrity issue stops
one utility or another from being able to interact with it correctly any
more.

If you want to keep areas uncapped, it might help to do a monthly SQREIDX
or SQFIX event to catch little issues before they become big/fatal issues.

 RT> Makes sense.  This also explains some why TimED's undelete
 RT> function seems to grab *all* deleted messages,  I guess that was
 RT> just simpler to code,  or something.

Yep...and probably has the same pitfoils as UNDELETE in DOS. 
"Deleted" data is overwritten by new data arriving...so some
deleted msgs are unrecoverable. TimEd is probably just grabbing all of the
puzzle pieces it can find to start with, figuring out which fit together,
and then throwing away the few leftovers that don't seem to fit anywhere
when done.

 RT> There are only a few areas like that here,  most are set for
 RT> specified
 RT> time frames,  typically 60 days.

SQUISH and SQPACK work together to maintain the quantity limit.  SQPACK
alone does the limit by days.  SQPACK should =always= show some shrinkage
on each daily run for areas with a days limit, unless the area is newer
than the limit or the area has days without mail.

.\\ike

--- GoldED 2.50+