Subj : file size issues? To : Mike Tripp From : Roy J. Tellason Date : Sun Aug 01 2004 05:07 am 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)