Beijing Paradise BBS Backup

home *** CD-ROM | disk | FTP | other *** search

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / 175B220U.ZIP / MFIX431.ZIP / MAILFIX.DOC < prev next >

Wrap

Text File | 1994-09-10 | 16.6 KB | 358 lines

MAILFIX v4.31 ------------- MAILFIX is a purge/repair/renumber utility for RBBS-PC message bases. It was originally written by Chip Morrow and released as part of the MAIL MANAGER offline mail door for RBBS-PC, but because of its obvious utility for all RBBS sysops, whether running MAIL MANAGER or not, we are releasing it as a free, separate stand-alone utility. Version 4.0 was largely rewritten by Doug Wilson to run much faster than previous releases, and has a few more useful options than previous versions. Significant changes and additions in this document from release 4.30 are indicated by a | symbol in the left margin. WARRANTY, DISTRIBUTION, AND LICENSING AGREEMENT: ------------------------------------------------ MAILFIX is 100% guaranteed to take up space on your hard disk, and is equally guaranteed to consume less space if deleted. MAILFIX is NOT guaranteed to do anything else. Period. MAILFIX is copyrighted 1991-1994 by Makai Software, all rights reserved. We are releasing it with source code, for those who would like to see how it operates. You may distribute it freely, provided that no modifications have been made. You are free to modify the code for YOUR OWN USE in whatever manner you wish. We are sure that the current code is far from optimal, but it does seem to work pretty well, nonetheless. MAILFIX is not "SHAREWARE", rather it is distributed freely with source code for other RBBS-PC sysops, as a contribution to the RBBS-PC community. See the top of the source code file MAILFIX.BAS for additional licensing information. CONTACTING THE AUTHORS: ----------------------- Due to the transitory nature of many bulletin boards, and the fact that you may be reading these instructions a long time after they are written, it is probably best not to list bulletin boards where we may be reached. Inevitably, whichever board we cite will immediately go out of business, and the phone number will be reassigned to somebody who does not care to be awakened by the phone ringing in the middle of the night when we modem junkies place most of our long distance calls. The authors, however, CAN be found on the "RBBS-PC" conferences carried by Fido and RIME. New releases are always announced in these conferences, and we occasionally post lists of the currently active distribution sites there. If you wish to contact us via these conferences, address messages to Doug Wilson or Chip Morrow. Current Makai Software releases are always sent to Compuserve within a few days of release, in the IBMBBS forum (GO IBMBBS). The doors themselves may be found in library 3, while the individually-distributed utilities (MNET, MAILFIX, etc.) may be found in library 2. While you're on Compuserve, you can reach one of the authors, Chip Morrow, there (72677,502). Chip Morrow is also available via Prodigy and Internet, if either of those are more convenient: Prodigy: GVHM95A Internet: 72677.502@compuserve.com And if all else fails, there's always good ol' U.S. Mail: Makai Software 870 Golden Drive Newark, OH 43055 ------------------------------------------------------------------------ LIMITATIONS: ------------ MAILFIX can handle, by default, RBBS message bases which contain up to 1000 messages. When it hits message 1001, it will exit with an error. You can increase MAILFIX's internal buffer by specifying /Snnnn on the command line, where "nnnn" is the maximum number of messages that MAILFIX should expect. So, if you'd like MAILFIX to be able to handle a message base containing as many as 3,000 messages, your command line would include: /S3000 The program would then not error out until it hits the 3,001st message in that area. With the /S switch, MAILFIX is compatible with RBBS mod packages which allow far greater than stock RBBS 17.4's limit of 999 messages per conference. | Prior to this release, exceptionally long messages (about 4k or longer) | sometimes caused MAILFIX to trash messages following the long message, by | not starting them at the 128-byte record boundaries. This seemed to | happen mostly when when renumbering the base. This bug has been | corrected with release 4.31 <he says with fingers tightly crossed, making | it very hard to type...> Aside from the above, MAILFIX has taken about anything we have thrown at it, as long as the file contains consistent 128-byte records. If something should insert or lose characters such that the 128-byte record length is not preserved, MAILFIX will not be able to process the file. ------------------------------------------------------------------------ USAGE: ----- MAILFIX [options] D:\PATH\MESSAGE.FIL Available options (must be separated by a space): /D - Use DOS screen writes instead of direct. Slows the program down a tad, but allows for DOS redirection of output. /F - Informs MAILFIX that this is a fixed-length message base. If "/F" is not specified, MAILFIX assumes the message base to be configured as 'elastic'. /Kn - (where "n" is the number of messages to keep.): Tells MAILFIX to trim down the physical size of the message base, keeping the last "n" active messages. This is useful for things like an echo area that grows almost out of control daily. If you want to keep 50 messages, your switch would be "/K50". This switch may not be used in conjunction with "/V"! Use of this option will OVERWRITE your original message file! /N - Tells MAILFIX to renumber the message base, starting at message number 1. If used with the /K option, the retained messages will be renumbered starting with 1. Use of this option will OVERWRITE your original message file! | After renumbering the base, MAILFIX will reset the user's | message pointers to reflect the renumbering. A default user | filename in the form xxxxxU.DEF will be derived from the message | filename specified on the command line, and in the same | directory as the message file. To specify a different user | filename, you may may immediately follow the /N with the | drive:\path\filename of the user file for this message base. There can be no spaces between the /N and the beginning of the filename. Your original user file will be updated in place, so if you want a backup of your unaltered user file, you must make one first. | If MAILFIX cannot find the default or specified user file, the | message base will not be renumbered, although other operations | will continue, as specified on the command line. /O - Informs MAILFIX that the sysop uses OverMail on this message base. OverMail formats the time field in the message header with a semicolon instead of a colon, which CONFIG's option #185 (repair messages) chokes on. /P - Tells MAILFIX to purge active personal messages which have been received by the addressee. /R - Informs MAILFIX that the sysop uses RBBSMail or MsgToss on this message base. Both of these mail processors format the time field in the message header with a period instead of a colon, which CONFIG's option #185 (repair messages) chokes on. /Sn - (where "n" is the max number of messages that could be contained in this message base). The stock RBBS-PC maximum is 999, and the default here is 1000 if /S is not specified. If you are running a modified copy of RBBS-PC (one that can handle more than 999 msgs per message file), then you will need to use this switch to increase MAILFIX's internal buffer. /V - Only View the integrity of the message file. Do not perform the actual repair work, and do not create an output file. | /Wx: - Define a work drive for MAILFIX to use when creating temporary | work files. If the specified work drive does not have enough | room, the directory containing the message file will be used | instead. D:\PATH\MESSAGE.FIL is the name of the messages file to purge/repair. Unless the /V option is used, MAILFIX will create an output file with the same name and the extension '.FIX'. Above example would | create D:\PATH\MESSAGE.FIX. If a work drive is specified which has | enough free space, MESSAGE.FIX would be created in the work drive | instead. If the /Kn or /N switches are used, MAILFIX will make a second pass on your message base, using the *.FIX file for input, and the original file name for output. When finished your original message file will have been replaced by MAILFIX's work, and the *.FIX file will be deleted. EXAMPLES: -------- Unless you use the "/Kn" or "/N" command line options, MAILFIX will not overwrite (or modify in any way) your original message file. If you want to replace your old message file with the one that MAILFIX creates, your best bet is to run MAILFIX from a batch file, like so: IF EXIST C:\RBBS\MAINM.FIX DEL C:\RBBS\MAINM.FIX MAILFIX C:\RBBS\MAINM.DEF IF EXIST C:\RBBS\MAINM.FIX DEL C:\RBBS\MAINM.DEF IF EXIST C:\RBBS\MAINM.FIX REN C:\RBBS\MAINM.FIX C:\RBBS\MAINM.DEF On the other hand, if you have an echo area named 4SALE that's scanned by RBBSMail, and you want to keep it purged down to 100 messages, your command line would be: MAILFIX /R /K100 C:\RBBS\4SALEM.DEF If you want to also renumber the message base, and to update the pointers in your user file for this base: MAILFIX /R /K100 /N C:\RBBS\4SALEM.DEF If you wanted to do the same thing with a message base that's been scanned by OverMail: MAILFIX /O /K100 /N C:\RBBS\4SALEM.DEF | If you wanted to do the same thing but use ramdrive e: as a work | drive: | MAILFIX /O /K100 /N /WE: C:\RBBS\4SALEM.DEF | If you have a conference whose files do not follow the ???????M.DEF | and ???????U.DEF naming convention for the message and user files, | you'll need to pass the full user filename when using the /N option: | MAILFIX /O /K100 /NC:\RBBS\USERS C:\RBBS\MESSAGES These last five examples would replace your original message base file with the fixed/purged/pruned message base. Run MAILFIX without a command line to get a help screen. ------------------------------------------------------------------------ TECHIE STUFF FOR THOSE WHO CARE: ------------------------------- If you run a mail system that utilizes RBBSMail, MsgToss, or OverMail for echo mail processing, you're likely to have run across the fact that the repair utility out of CONFIG (option #185) no longer works for you. This is due to the fact that these mail processors place either a period or a semicolon in the time field of the message header on every message that they process. This just happens to be one of CONFIG's five "key fields" that it looks at to determine whether or not the message is corrupt. These key fields are: Description Should be ------------------------------------------- --------- The "killed" flag, Ascii 225 or 226 "ß,Γ" the first separator in the 'time' field, ":" the second separator in the 'time' field, ":", ".", or ";" the first separator in the 'date' field, "-" and the last separator in the 'date' field. "-" Therefore, this string of five characters is very important, and is what will be displayed to you if the message needs repaired, and you specify the "/v" option on MAILFIX's command line. If you don't specify "/v" on the command line, MAILFIX will do its best to fix the message, and report "<fixed>". If you use a mail processor on your RBBS-PC message bases OTHER than RBBSMail, MsgToss, or OverMail, and said mail processor *DOESN'T* use a period or semicolon as its 'mark' in the second separator in the TIME field, we'd sure like to hear about it so that we can attempt to make MAILFIX compatible with your system. WHEN, AND HOW MAILFIX FIXES A MESSAGE: ------------------------------------- To determine whether or not a message is valid, MAILFIX looks at the following in the message header: Message number - Should never evaluate to zero. Killed flag - Should always be ASCII 225 or 226. Number of 128-byte records - Should never evaluate to less than 1. If the message header passes these three tests, MAILFIX assumes it has a valid message on its hands, and moves on to do one of three things: - Copy it (if it isn't marked as killed, and doesn't need fixed). MAILFIX will step through the message's records and write them to the output file. - Fix it (if it isn't marked as killed). If, during all of its checks, MAILFIX finds that it has a valid message on its hands, yet the five key characters mentioned above DON'T MATCH what they're supposed to, the message header is adjusted as follows: * Sets the "killed" flag to indicate that this is an active message (Ascii 225) "ß". * Sets the TIME separators to: :: - RBBS-PC (un-scanned by RBBSMail/OverMail) :. - RBBSMail and MsgToss :; - OverMail You must have specified "/R" or "/O" on the command line for the RBBSMail/OverMail checks to take place. If "/R" or "/O" is specified, MAILFIX is smart enough to discover whether or not the message has been scanned by either one of these mail processors yet, and will not mark an un-scanned message with the special "." or ";" separator. * Sets both DATE separators to "-". - Purge it (if it's marked as killed). MAILFIX will skip the entire message (and its records) if the message is marked as killed (ASCII 226) "Γ". If the message didn't pass the tests, MAILFIX assumes that this is not a message header, reports to you as such, purges the offending record, and moves on to the next record until it finds the next valid header. ------------------------------------------------------------------------ *=- ABOUT MAILFIX and MESSAGE BASES with CARBON COPIES -=* -------------------------------------------------- MAILFIX *DOES* work with message bases that have been configured with the new "carbon copy" feature of RBBS-PC v17.4. MAILFIX does not go through any special gyrations to look for multiple-recipient messages, but it will not trash your message base, either. When renumbering, it will reset the message number in all "carbon copies". In the 3+ years of Mail Manager / MAILFIX's life thus far, we have found that there are MANY utilities floating around out there that do not strictly adhere to the RBBS-PC message format as-defined in the documentation for our favorite BBS software. MAILFIX was specifically written to be as generic as possible, and to work with the widest possible variety of RBBS-PC message bases. The only incompatibility with RBBS-PC v17.4 message bases is the following scenario: The message base is configured with "carbon-copy" turned on, and 1) - The very first header of the "carbon-copy" message is bad, or 2) - The very first header of the "carbon-copy" message is marked as "killed". In the first case, MAILFIX will skip the "bad" message, and maybe the one following it as well, until it can get its bearings and find the next "good" message header. In the second case, MAILFIX will purge the entire message, even if some of the other carbon copies have not been marked as killed.