Subj : file size issues? To : Mike Tripp From : Roy J. Tellason Date : Tue Dec 14 2004 12:09 pm Mike Tripp wrote in a message to Roy J. Tellason: MT> Hello Roy! MT> 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... MT> I was referring to your new replacement files here, not the MT> original hosed version. If you don't assign it any purge MT> paramaters either, then there's no reason for SQPACK to ever shrink MT> the file, and it should head straight back for 8mb or however far MT> it grows until it a data integrity issue stops one utility or MT> another from being able to interact with it correctly any more. A data integrity issue? Hmm. MT> If you want to keep areas uncapped, it might help to do a monthly MT> SQREIDX or SQFIX event to catch little issues before they become MT> big/fatal issues. I never thought about sqreidx, missed that one completely. Sure enough, there it is, right in my squish directory where it should be! Actually what I plan on doing is archiving the stuff I want to keep about once a month (keeping it in month-sized chunks) and then deleting those from the active message base. What I put off for *way* too long with this particular area, since the archives I did end up creating go all the way back to last November. 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. MT> Yep...and probably has the same pitfoils as UNDELETE in DOS. MT> "Deleted" data is overwritten by new data arriving...so some MT> deleted msgs are unrecoverable. TimEd is probably just grabbing all MT> of the puzzle pieces it can find to start with, figuring out which MT> fit together, and then throwing away the few leftovers that don't MT> seem to fit anywhere when done. Or something. I don't use it that often to be able to guess. RT> There are only a few areas like that here, most are set for RT> specified time frames, typically 60 days. MT> SQUISH and SQPACK work together to maintain the quantity limit. Yeah, which is why I use it seldom, since it slows down message tossing. MT> SQPACK alone does the limit by days. SQPACK should =always= show MT> some shrinkage on each daily run for areas with a days limit, MT> unless the area is newer than the limit or the area has days MT> without mail. Sounds right to me! I just wonder what the problem was. Oh well. I won't likely be letting any area get that big again so I probably won't run into the problem again... --- * Origin: TANSTAAFL BBS 717-838-8539 (1:270/615) .