Subj : Max. number of messages.... To : Bob Jones From : Mike Bourne Date : Sun Aug 10 2003 03:58 pm MB> I have a Squish question that I have not been able to MB> find the answer for in the documents. BJ> ... MB> The question I have is: With Squish and a *.msg MB> message base, is there a maximum message number that MB> can be handled? Back in "the old days" I would use the MB> renumbering feature of CONFMAIL to renumber the MB> messages periodically to keep the ranges more MB> reasonable. BJ> It depends on your OS, Windows for Workgroups 3.11 (I know, obsolete. But it has been running virtually error free and non-stop for about 11 years now, with only a memory upgrade and a harddrive upgrade in that period. Oh, and a couple monitors too.) BJ> the binary you are running, It came from the archive SQSH_111, and refers to version 111 in the docs. BJ> the type of BJ> message base you have and how you have formated the disk partition BJ> you store the messages on. It is a subdirectory of the root, so there are fewer directory related issues. MB> And I am using *.msg format because I have become MB> rather comfortable with them over the last 15 years or MB> more of being a point, and why change a known good MB> thing? :-) BJ> Since you are using *.msg, I believe your limits will come from the BJ> partition you are using for the message base. If I remember BJ> correctly, there is a maximum of about 512 files in the root BJ> directory of a FAT partition. Since there is one file per message BJ> in *.msg format, that gives you an idea of the limit. Since BJ> subdirectories on a FAT partition are not as limited to the space BJ> taken up by the directory contents, subdirectories on FAT BJ> partitions can have significantly more files.... That has not been a problem as there are only a few thousand messages there, but the message numbers are getting up there (in the 22,000 range). BJ> But too many files will hit access speed issues. It is a bit slow at times, but an occasional cleanup and defrag works wonders. BJ> I'm not sure what the limits BJ> are on HPFS and NTFS paritions, but I expect those are relatively BJ> high. Virtually unlimited, with any reasonable disk size, for NTFS. I don't have much OS/2 experience. BJ> For Max itself, (if using the BBS code to read the areas), there BJ> may be a 32K limit in that code (due to access via a message BJ> number). Maybe the limit is 64K. Maybe the limit is 4Gb.... I BJ> haven't looked at the code to see. No BBS here, just a point with TimEd, with the Y2K patches. BJ> As to squish message bases, running under OS/2, with the sq386p BJ> version of the code, I think I've had areas with over 20K messages BJ> in them. There is a point at which some of the related tools will BJ> break (such as the squish tools used to fix broken databases). And BJ> I have had squish process squish style message bases that the BJ> squish tools (under OS/2) couldn't handle due to number of BJ> messages. I think the limit is around 10K to 16K messages under BJ> regular DOS. I don't think I took any message bases above about 5K BJ> messages when running the DOS (16 bit) version of the squish BJ> code.... No squish message bases. BJ> For dupe file checking, from memory, just over 3K was the limit of BJ> what is handled by the dupe checker, so make sure you don't toss BJ> old message back out of your system on a rescan.... I'm pretty careful about that, and do not automatically send out packets. I manually run an "export" to send out messages. MB> I guess that I could get the SQUISH source and check it MB> out myself, but with only most weekends and about every MB> third or fourth workweek in town, that might take a while. I guess that I will need to look at the code. Or I could just catch up while I am in town for a few days. :-) Mike Bourne --- timEd 1.10.y2k * Origin: A Point at the Edge of Town, Ft Worth TX USA (1:130/41.3102) .