Text 8, 87 rader
Skriven 2004-08-01 04:07:32 av Roy J. Tellason (1:270/615.0)
      Kommentar till text 7 av Mike Tripp (1:382/61)
Ärende: file size issues?
=========================
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.  <shrug>

 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?

--- 
 * Origin: TANSTAAFL BBS 717-838-8539 (1:270/615)