PC Online 1998 November

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

/ PC Online 1998 November / PCO_1198.ISO / filesbbs / dos / tftp156.exe / TOSSFTP.HST < prev next >

Wrap

Text File | 1997-06-21 | 26.4 KB | 474 lines

TOSS'in for FTP'in Copyright(c) 1995, by Lyn Borchert All Rights Reserved [ Revision Log ] 01/27/95 - Pre-Release Beta v1.00b The first beta test version to leave the nest. This one doesn't do much, just packetizes Areafix and Raid type messages destine to the uplink node with minimal message fiddling. 01/29/95 - Pre-Release Beta v1.30b Spent considerable time developing the Bit manipulation routines so I could not only read the msg header flags, but also write them out. There are certain flags that *should* be toggled off when the message leaves a system. At this point I'm still not doing that and so far it really doesn't seem to be causing any problems on the type of messages I've been tossing. But, now that I'm going to start dealing with host routed netmail, I suspect I'm gonna have to be more conforming to the rules. :) I also spent considerable time working on the NOROUTE: keyword for the config file. Had to build the routines to read it in, and then separate out the zone:net/node numbers into a 3 dimentioned array. The really hard part was getting a good working algorythem for processing these NOROUTE entries. It was a real brain teaser, but I think the method I ended up with works very fast and should deal with things correctly. I did make some assumptions about host routed messages. In order for TOSSFTP to consider a message to be a host routed message, several conditions have to be met. I'll list them below and if there are some host routed messages not getting routed that you think ought to get routed, you'll need to let me know. I'll need to get from you, what, if any of the following conditions was the cause of the failure to toss, why that is no good for you, and then I'll see if I can't work around it. Otherwise, it stays as it is. To be considered a host routed netmail message, the following conditions must be met and are checked in this order; 1) The message must have the FWD or IN TRANSIT flag turned on. 2) The message must NOT have the Sent flag turned on. 3) The message must NOT have the Hold flag turned on. 4) The message must NOT have the FD DIRECT kludge line. 5) The message must NOT be destine to your Net. 6) Finally, the message must not fail the NOROUTE: checking. If all these conditions are met, the message will be packetized and deleted from netmail. Squashed a nasty bug in the config file reading. TOSSFTP wasn't ignoring the semi-colon lines. It wasn't a problem as yet, but could have been a bad problem in a heavily commented config file. The toggling off of the handful of flags, will need to be implimented before another release can be done. Hopefully I'll take care of that in a day or two. The amount of work done today warrants an increase in the version number by .30 I've pretty much decided that once the host routing features have been tested for a few weeks without trouble, I'll release a "wide beta" copy with a drop dead in it. Not sure how popular this little utility will be, but the wide beta release should tell me that over time and at the same time, help to find any potential problems prior to a normal release. 01/29/95 - Pre-Release Beta v1.40b This one is now ready for testing I think. TOSSFTP will now properly set the flags on all messages it packetizes. (fingers crossed) I haven't done any testing on this yet, so be careful. Do a "test" run before commiting it to handling the job for you. (make a backup of your mail before running this version just incase the uplink refuses it or it packages up the wrong mail) If this one works, we are almost ready for a release I think. Just a little tweeking of the routing stuff might be in order and I won't know until it's been in use for a while. I think version 1.50 will be the first official release of the program. 01/29/95 - Pre-Release Beta v1.41b Ok, this time I got it for sure! (fingers crossed) Re-hashed the NOROUTE logic section which was really messed up. Must not have been thinking too staight when I wrote that section before. Anyway, the IN TRANSIT bit is no longer looked at, TOSSFTP doesn't care about it anymore. In it's place now, it checks for the File Attach bit. File Attach messages are not allowed to be host routed any more. Multiple NOROUTE statements are now parsed properly. (previous release was only parsing the first one) Zone numbers are still required. (haven't decided how I'm going to deal with 2:* yet, so it's not really a valid NOROUTE arguement) Due to the method I'm using to create PKT names, I had to insert a pause during processing of host routed mail. If a message is determined to be a message that needs to be packaged up, it will pause for one second after packetizing the message. PKT filenames are generated based on the number of seconds since a particular time and without the delay, TOSSFTP was going so fast that a multiple messages would get written over top of each other because it was packing 4 to 5 messages a second. That wasn't enough time to let the filename generator come up with a new filename. So, don't be concerned if you see TOSSFTP pause for a second, it's supposed to do that. (but only have tossing an outbound host routed netmail message) Added the packet names generated to the log file. Beta testers should look at these names once in a while and tell me if they ever see the same PKT name created more than once during a single run of TOSSPKT. If you see that, it means that the first message was overwritten by the second message to generate the same PKT name. It shouldn't ever happen, but it could and if it does, I need to know about it ASAP so I can add more code to prevent this from happening again. 02/26/95 - Pre-Release Beta v1.41c Dog gone it, found yet another problem with the packet naming process that was causing successive outgoing messages to be tossed on top of each other. This time I know I fix it for good! The release is a bug fix to the EXE file only. Update by simply overwriting TOSSFTP.EXE with the new one. Haven't had much time to work on this lately, sorry for such a delay in getting another release out. I'll try and do better in the weeks to come. :) 02/26/95 - Pre-Release Beta v1.43 Another Routing Logic Battle has been won! Thanks to Tom Creek for pointing out a problem with the NOROUTE processing. This was a pretty subtle problem, so to find it and for possible future such problems, I've added two new Config Keywords. DEBUG:ON | OFF will turn on lots of extra printing during routed netmail processing. This should make it easy to figure out just why TOSSFTP isn't packing up a routed Netmail that you think it should or why it is packing up a routed Netmail that you think it shouldn't. DELETE:ON | OFF will cause TOSSFTP to either delete all routed Netmail messages it packetizes or NOT. If DELETE:OFF is used, TOSSFTP will simply turn on the SENT flag and leave the *.msg file alone. This stuff took me several hours to add and fix, so it seemed appropriate to jump the revision number up to 1.43 this time. 03/30/95 - Pre-Release Beta v1.44 Improved large .msg handling. TOSSFTP should now skip over any messages that exceed it's size limits. (I know, .msg files are not supposed to have a size limit, but for ease of programming I have set a limit that is more than reasonable) If a .msg exceeds the limit, TOSSFTP will log that fact and skip the message instead of hanging your system. 05/30/95 - Pre-Release Beta v1.44 extended The beta program has been extended with this version. I've decided to take it another 150 days from today simply because I've fallen behind in my developement plans. I've just been too busy at work to devote any time to TOSSFTP these past couple months. Fortunately, I've received very little mail from the beta testers, so it would seem that the program is fairly stable in it's current condition. 06/04/95 - Pre-Release Beta v1.45 Tom Creek found another nasty problem. (notice I'm not calling it a bug!) It would seem that there are some AreaFix programs that can create a .msg that allows garbage in the message header behind the TO: (and other) fields. While this isn't really against Fido Technical Standards, it is in my opinion, a very poor programming practice. According to the FTS, the fields must be NUL terminated. To me, that means, if you have a 36 character field and you put a 10 character string in that field, the remaining 26 characters will be NUL. The problem was that some programs where making the 11th character a NUL and the remaining 25 characters would be whatever junk was on the hard drive at the time. Not only does this make more work for TOSSFTP to clean out the junk, but it makes if very difficult to use a HEX editor/viewer to find problems with the header structure. It just looks like a bunch of garbage rather than a nicely formated structure. Plus, these junk characters are kept by the compression program whereas 26 nuls will be represented thus causing better compression of the message. Granted, these are all minor things, but for systems with large message traffic, these little things would add up fast. These are common practices by many C and Pascal programmers simply because they tend to read and write files once character at a time rather than the more efficient Block Read & Write methods. At any rate, with a slight processing speed reduction, TOSSFTP will now deal message created with these kinds of practices. DELETE:OFF enhancement For those of you who prefer to manually delete sent mail, I've expanded the delete off feature to include Areafix and Filefix messages. They will now simply be marked as SENT rather than deleted and future program runs will skip over any messages that have the SENT flag on. This behavior is also logged. New LOGFILE: Keyword (Optional) By request, you can now tell TOSSFTP where to place it's logfile and what to name the file. Look at the sample TOSSFTP.CFG file in this archive for specific instructions on how to use this new feature. I've made it an optional keyword. If TOSSFTP does not find this keyword, it will simply go back to the default of writing TOSSFTP.LOG to the current directory. Lastly, I'm changing the method of distribution with this release. We now have several people running TOSSFTP and as a result, it's becoming a pain in the butt to send everyone a file attached E-mail with the new releases. So, I'm now going to make it available for file request from 1:300/1 at speeds up to 28.8k. The most recent version will always be available via the magic name TOSSFTP, 23 hours a day. One last thing, if you are reporting a problem, please include a copy of your TOSSFTP.CFG and a clip of your log file that was created in DEBUG mode showing the error (or not if it didn't register). Send them to 1:300/12 or you can E-mail them to lynb@primenet.com. Keep in mind that I only check E-mail a couple times a week, but Netmail on 300/12 is seen several times a day. 08/18/95 - First Full Release v1.50 Minor bug fix. TOSSFTP should now handle *.msg files named with numbers higher than 32,000. Who would have ever thought someone would have more than 32,000 *.msg files in their netmail directory. :) New feature suggested by Tom Creek. Errorlevel Setting. TOSSFTP will now set an exit errorlevel of either 0 or 1 depending on whether it did any tossing or not. An errorlevel of 0 means it did NOT toss any *.msg or echomail bundles. An errorlevel of 1 indicates that something got tossed. Thanks Tom. Documentation re-write. With this being a full release the docs now contain all the license and disclaimer information. Please read through this stuff. (at least once) Just so you know where you and I stand. This version is the first to not contain a "drop dead date" embedded in it. Instead it will start beeping and pausing after a 30 day evaluation period unless there is a valid serial number in the config file. 11/04/95 - Bug Release v1.54 Fixed a few problems as follows. Tom Creek reported that the errorlevel setting was only happening if we tossed host routed netmail and not when the program only tossed an echomail bundle or two. I decided to fix and enhance this a bit. With this version, if an echomail bundle was tossed, the errorlevel will be set to 1. If a host routed netmail message is tossed the errorlevel will be set to 2. And if both operations take place the errorlevel will be set to 3. Another bug caught by myself first and reported by a couple others was that TossFTP would frequently not toss some routed netmail until a second or third run of the program. Instead it would simply report the message destination and then go on to the next message. This was really a very difficult bug to trace down, but trace it down I did. To be breif, the problem was the result of the variable containing the AreaMgr's Destination address being trampled with the address of the most recently tossed message. The result was the first routed netmail message encounted was tossed correctly and none after that. Echomail bundles were not affected by this. It's now fixed. Yet another suggestion by Tom Creek. (I may have to give him some money for all his assistance here) It seems that TossFTP didn't care what was in the outbound directory. Normally not a problem, but if you had copied an echomail bundle over manually and manually truncated the source file and FORGOT to delete the file attach message... The next run of TossFTP would (you guessed it) copy the zero length file over top of the file in the outbound directory. Affectively and irreversably deleting that outbound mail. For safety's sake, TossFTP now checks for the existance of the destination file before doing a copy and if it exists it exits the program immediately with an errorlevel to denote the cause of the problem. It does not continue processing the rest of the mail. File Sharing has been added. I've added the code necessary to get along with other multi-user software. This is not fully implimented in this release, but TossFTP will now correctly "share" and "lock" files that it is making use of. If it is unable to get a lock on a file, it will still generate an error and skip to processing the next message. In the future, I may make it continue to attempt to get the file lock. Right now, I don't think that is such a good idea because it could cause TossFTP to end up in a continous loop. I still maintain that if you operate in a multi-node environment that you MUST take down all nodes that would have anything to do with your *.msg directory when running TossFTP. This is the ONLY way to be sure the messages don't get renumbered in the middle of a TossFTP session (which would cause extreme damage) and it's the only way to be sure no other program has a message file locked preventing TossFTP from working on it. Lastly, for this release, I've re-written the error-trapping code. Included in the archive is a file called ERR.TXT which contains all the errorlevels that could be set by TossFTP based on certain conditions. Basically, you can consider any errorlevel between 100 and 255 as a fatal error. There are some errors that are higher than 200, but they are very unlikely to ever happen. In this version, TossFTP will continue processing even though a fatal error was encountered. This is a potentially dangerous situation, however, it should not cause any damage other than to possibily to the message that caused the error in the first place. 11/04/95 - Interium Release v1.55 It appears that some mail tossers are very nit-picky about short packets. A "short" packet is a PKT that doesn't have a PKT termination character ending it. In my opinion, this should not be a "fatal" error causing stopage of mail delivery. Afterall, the format of the message inside the PKT is correct and complete, the PKT header is correct and complete. If the tosser gets to the end of the PKT without experiencing any errors in format of the messages processed so far, why not just stop processing? At most maybe write to the log that the PKT ended without a PKT terminator, but still process the PKT and deliver the mail. Apparently, there are some tossers that treat this as bad mail and refuse to deliver the mail when there is only one NUL ending a PKT instead of 3 NULs. As a result, this version of TOSSFTP will now create PKT files with the 3 NULs ending the file. Hope it doesn't break anything else. :) During this quick release I also took the time to add a command line argument. For those of you who have more than one DEST system, you can now place the full path and filename of the *.CFG file you wish TOSSFTP to use. If no command line arguement is found, the default of TOSSFTP.CFG will be used. If the alternate *.CFG file is in the current directory, you don't need to specify the path to it. Examples Follow; C:\TFTP\> TOSSFTP Uses TOSSFTP.CFG located in the current directory C:\TFTP\> TOSSFTP c:\mail\toss2.cfg Uses TOSS2.CFG located in the c:\mail directory C:\TFTP\> TOSSFTP toss3.cfg Uses TOSS3.CFG located in the current directory The purpose of this addition is to allow systems to run TOSSFTP multiple times with different config files in order to toss mail to different uplink systems. It's not likely that TOSSFTP will in the future have the ability to have one config file reflect multiple uplink systems in order to process all systems in one pass. The main reason is because virtually everything in the CFG file would have to be duplicate'able. Since TOSSFTP doesn't really take all that long to do it's thing and using multiple CFG files will accomplish the same task, I'm not convienced it's worth my effort to support multiple DEST nodes in one CFG file. Maybe in the future I'll decide differently, but for now this will have to do. Finally, I did some tweeking of the status bar that displays during *.MSG gathering and sorting. It should look nicer on systems running FAST machines with large numbers of Netmail messages. The only purpose for this thing is so you can tell whether TOSSFTP is actually still doing something or is hung. When you have several hundred Netmail messages for TOSSFTP to scan and sort, it can take several seconds to do it. In the past, it would look like TOSSFTP was hung while this processing took place, so I added this little ditty to indicate processing was still going on. It adds a very small amount of overhead to the sorting, but I think it was worth the sacrifice. (Keeps my heart from stopping anyway) There you have it, for the New Year. I seriously don't intend to release any new versions in 1996 unless something drastic happens. The next real release will be a substantially different program implimenting several rather major changes to TOSSFTP. At that time, I will probably make a feature-less, free to use version and slightly increase the registration for the new release. Whether I ask current registered users to kick in some more dollars for the new release is not decided and I don't expect to decide til I see the end results of my labors. At worst, they may have to pay an upgrade fee that will be less than new user registration. But it will be worth it. Some of the things I'm interested in doing to TOSSFTP are; Make it Zone Aware Totally re-vamp Routing control Selective PKT Types Support for Non-Echomail OUTBOUND File Attaches Improved processing speed Support for a SQUISH Netmail File FD & IM Semaphore Support Support for Other Mailers Improved Multi-Node Operation Direct Comm & FTP via PPP/SLIP implimentation making TOSSFTP the only program you need to connect and send/receive your files. The last one there is a BIG if, but none the less, it's something I'm interested in doing. Have a GREAT 1996 guys and gals. 06/20/97 - Update Release v1.56 Wow, has it really been almost a year and a half? Well, 1996 was a holiday year for me. You will all be happy to know I've started work on v2.00. I did decide to create a new configuration program and data file. It does support multiple destinations and is nearly complete. After that I'll start on the revisions to the actual tossing program. With some luck we might see v2.00 round the first of 1998. For this release, I did some cleaning up of the niffty little status bar. It should work much better. I know I keep saying that, but I'll get it one of these times. I corrected some spelling errors that have been pointed out by users. I'm also dropping out of national echomail distribution, so I won't be able to read the FTPHUB echo anymore. I needed to get a new release with revised contact information in the documentation and wanted to do so before my access was terminated. My BBS will remain alive and a member of Fido. 1:300/12 So you can still reach me via Netmail at that address. I'm also on the net with a perminent E-Mail address of lyn.borchert@usa.net The latest version of TossFTP can be gotten from my website currently http://www.dakotacom.net/~lynbor and soon there will be a mailing list you can join to get support as well as future release information. More on that later. The website is probably the most "if'y thing" since it's address changes if I change my internet service provider. I'm sure George Peace will continue to keep a recent copy available at his FTP site and Mike Jordan's site at ftp.europa.com in /outgoing/tossftp/