Mike Tripp wrote in a message to Roy J. Tellason:

 MT> Hello Roy!

 MT> 31 Jul 04 12:13, Roy J. Tellason wrote to Mike Tripp:

 RT> -        672 - Old=1131352; New=1131352

 RT> This is after I'd trimmed out a bunch of stuff...

 MT> The file should've gotten smaller the first run after you deleted
 MT> messages.

One would think so.  It had gotten pretty large,  something over 4000 msgs,
 and over 8M in size.  I wrote out what I wanted to keep,  by month, 
deleted the rest,  and tried to run sqpack manually -- and that's when I
got the error.  A shot at sqinfo -b gave nothing,  and sqfix gave me the
same error.

 MT> Even without parameters, SQPACK should purge the "slack space" 
 MT> occupied by the deleted messages.  Even if you trim to a specific 
 MT> quantity of messages, the 5K you have today may be fewer bytes 
 MT> than the 5K you had yesterday.  If that's not the case, then 
 MT> you'll see the same bytes reported for Old/New as above.

I'm seeing the same numbers in both cases there because I have no settings
in the area.  Most of them here are set to some specific time limit
(commonly 60 days at this point),  one or two of the real busy ones are
also set to a maximum number of messages,  but I try to avoid that because
it slows down tossing.  That way I don't have to worry about feeding any
parameters to sqpack in my batch file other than a wildcard pointing to the
directory,  and can change the settings on the fly here in TimED,  as well
as with sqset.

 RT> 5400 messages?

 MT> That seems to be where GoldEd/DOS starts complaining...GoldEd/2 is
 MT> still fine beyond there...and your editor may have no trouble.

It didn't seem to.  I used to use GoldEd but stopped,  I can't recall why
just now.  I know the last time I tried it out I didn't care for it,  or
was too used to this,  or something.  

 MT> I forget the magic number where SQFIX starts suggesting that you 
 MT> use SQFIX32 instead...but I use the lowest common denominator, 
 MT> which for me happens to be the editor's limit. 

 RT> There were something over 8000 of them in there, I
 RT> forget how many now.

 MT> 672 according to the line above...and now you have a 1mb file
 MT> instead of the 8mb you originally asked about.

Right.  But to get to that point I had to *move* the remaining messages I
wanted to keep from one area to another.  I created a new area,  same name
as the other one but with a "2" at the end of the area name and
no links listed in squish.cfg,  fired up TimED again,  and it found it.  I
moved everything over there (and didn't get that "moved" string
implanted in the messages thankfully),  exited the editor,  and in my file
manager deleted the old area and renamed the new one,  then fixed my
squish.cfg.

In other words the software didn't work for me the way I expected it to, 
and I found a workaround.  Which is pretty typical.  But also why I posted
on this in the first place,  to find out if there's some known point when
things get messed up.  I know that this is definitely the case with largish
text files under dos!

 RT> And yes, this is the dos version.

 MT> And you will have different luck between the 16- and 32-bit DOS
 MT> versions of SQFIX, but my experience is that is the message
 MT> quantity (.SQI index entries) and not the filesize of the .SQD that
 MT> makes or breaks you.  It's not that rare that there is some index
 MT> cleanup even on areas with low caps and small .SQDs, and both SQFIX
 MT> and SQPACK have to manage these while doing their thing.

That would be the .sqi file?  Here's what I'm looking at now for the area
in question:

.sqb            20008
.sqd          1208034
.sqi             8628
.sql                4

All with today's date,  and a timestamp within the past hour when I was
reading it last.  What's that sqi file used for anyhow?

---