Zipfile Duplicate Checking System (ZDCS) Ver. 1.6 Copyright (C) 1991, Michael W. Cocke -------------------------------------------------------------------- 1. INTRODUCTION - What is ZDCS? ZDCS is a shareware set of utilities intended to help a sysop deal with the problem of duplicate files in ZIPs, GIFs and SFXs (self-extracting EXEs), whether those files are already on the bbs or are being uploaded by a caller. It is compatible with any Netbios compatible lan, such as Lantastic or Novell. ZDCS is very simple to set up and run, but still provides the sysop with the flexibility of deciding when to decline an upload (if ever) and which duplicate files to automatically remove from an upload (if any). Version 1.6 also supports pre-testing, which permits a bbs caller to "pre- test" a ZIP to see whether or not it duplicates files already on the bbs. This short manual will describe how a sysop can use ZDCS, including the sysop-configurable options, and will take you through the steps needed to install and configure ZDCS. License and registration information are provided in section 13. 2. FILES IN THIS RELEASE - What should this package contain? File Name Description ------------ ---------------------------------------------------- PCBTEST.BAT A sample PCBTEST.BAT file, suitable for use with older versions of EXZTEST (prior to 2.0) and ZDCS, for PCBoard systems. PCBTEST.ALT A sample PCBTEST.BAT file, suitable for use with EXZTEST version 2.0 and higher and ZDCS, for PCBoard systems. ZDCS.CFG A sample configuration file for ZDCS. ZDCSDB16.EXE The utility program to create the initial database. ZDCSBA16.EXE The utility program used to add bbs ads to the separate bbs ad database. ZDCSDR16.EXE The report generating program that produces the list of duplicate files within the database. ZDCSFC16.EXE The program module to perform a real-time test for duplicates (as soon as the upload is received). ZDCS16.TXT A rambling text file full of useful and other kinds of information. (You're currently reading it.) ZDCS.ADN A sample listing of allowed duplicate files. ZDCS.BLT A sample bulletin (ASCII text) explaining to callers how to use the ZDCS pre-test feature. ZDCS.NEW A last minute text file with changes and notes. 3. GENERAL INFORMATION - What's going on? ZDCS was intended to be used on a specified collection of ZIP files, such as those found on a bbs. With this release it also handles SFXs (self- extracting EXE files) created with PKSFX. Both types of files are treated in a similar fashion by ZDCS. The differences are spelled out in this manual. When ZDCS encounters a file that does not fall into one of these groups, it treats the file like a black box and calculates the CRC for it. This capability was included to provide support for bbs's that carry GIF files, but ZDCS will treat any "other" file as a GIF, too. Note that since ZDCS does not look inside the file to see if it is an ARJ, LZH, or other type of file, it cannot "see" individual files inside a non-ZIP type of archive. All of these "other" files will be referred to as GIF files here, for the sake of simplicity. ZDCS thinks of such a GIF file as a poor ZIP with only one file in it. The original application I had in mind was trying to weed out duplicate files from a bbs file collection and to test new uploads against the bbs files for duplicates, so that's how the package was assembled. ZDCS was designed specifically for PCBoard 14.5 and higher. (Although it may be possible to use it with other bbs software, this manual will attempt only to describe its detailed use with PCBoard. Wildcat 3.0 sysops interested in using ZDCS on their systems are encouraged to contact me about beta testing a slightly modified form of ZDCS.) First, ZDCS has to check out the initial collection of ZIP and GIF files. This provides a database against which any new upload is checked. Of course, every new upload accepted by the board is then added to the database, making it ready for testing the next upload. This automatically keeps the database current. The files are checked by keeping a database of the 32-bit CRC used internally by PKZIP for ZIPs and SFXs or calculated by ZDCS for GIFs. These CRCs are then compared to the CRCs for the files in the new upload against those stored in the database. The database of CRCs uses a B-tree index, so there are no sort utilities or regular file maintenance requirements of any kind. When a caller uploads a ZIP or GIF file, ZDCS goes to work on it to detect any duplicate files. This is easy to set up since ZDCS was designed specifically to "plug into" PCBTEST.BAT, right behind EXZTEST version 1.x. With the new EXZTEST version 2.x, it's even easier: EXZTEST will be able to call ZDCS directly. (EXZTEST is a wonderful sysop utility written by Andy Keeves and it does a perfectly credible job of swapping ZIP comments, using external test programs to identify viruses, detecting damaged ZIPs, and so on.) What happens to duplicate files depends on how the sysop has set the ZDCS options as described in the next section. 4. CAPABILITIES - What will ZDCS do? ZDCS allows the sysop to mix and match among four different options for the processing of uploaded ZIPs. The first option is setting the maximum percentage of duplicates in an uploaded ZIP. ZDCS will calculate the actual percentage of duplicate files in the ZIP and will compare it to the maximum number selected by the sysop. A GIF, since it is treated as a single file, will either be flagged as a duplicate (100%) or not (0%). If the actual percentage is greater, the upload will be declined. (The PCBoard code takes care of moving these declined files into your private upload directory, where you can review them.) The percentage is configurable by the sysop to any whole number from 0 to 100. Setting the percentage to 100 effectively bypasses this filter, since it permits an uploaded ZIP with nothing but duplicates to pass. At the other extreme, setting the percentage to 0 effectively requires that the uploaded ZIP have no duplicates at all. The second independent option that can be selected by the sysop is the removal of *all* individual duplicate files from the uploaded ZIP. When this option is selected, all files within the ZIP that have CRCs already listed in the database are removed from the ZIP, leaving the remainder of the uploaded ZIP intact. This feature does not operate on a GIF file. A note of caution about this second option, the removal of *all* duplicate files: some shareware authors issue updates that consist of both new files (executables, perhaps) and unchanged files (registration information, for example). If you enable the deletion of all duplicate files in an uploaded ZIP, you will lose some of the files that belong in the author's package. The third option is the removal of *designated* duplicate files from the uploaded ZIP. A separate database is created with the CRCs of all files that are to be removed. This is a great way to clear out all those blasted bbs ads from you-know-who, without removing authors' unchanged text files from newer shareware versions. In fact, the database of files that you want to always remove from uploads is referred to as the bbs ads database. Again, this feature does not do anything to a GIF file. The fourth option is the use of a list of allowed duplicate files. You can create a list of file names and/or CRCs that you do not want ZDCS to see as duplicates. Filenames are preceded by $ and CRCs by #, with one file per line for a maximum of 256 lines. (A sample list is included in this package.) Why would you want to have allowed duplicates? There are some files that reappear frequently as part of shareware or freeware packages, such as OMBUDSMN.ASP (found in ASP-ware), or VALIDATE.DOC and VALIDATE.COM (from Macafee's SCAN program). Especially in a case like Macafee's where new versions of the program come out frequently, each with certain standard files included, it would be useful to "recognize" these duplicate files as being acceptable. This feature does work for GIF files. If a GIF is included among the allowed duplicates, then a repeat upload of the same GIF will not be flagged as a duplicate, and the upload will be accepted. Once an uploaded ZIP or GIF file has been either accepted or declined, the CRCs of the individual files in the ZIP are automatically added to the file database so that the system will recognize any future uploads of the same files as duplicates. No CRCs are automatically added to the bbs ads database. That must be done with one of the other utilities in the ZDCS package. 5. INSTALLATION - How do I get ZDCS up and running? There are four basic steps to installing ZDCS to work with the bbs: A. Setting up the configuration file. B. Creating the initial database. C. Creating the bbs ads database. D. Setting up the check for uploaded duplicates. Each of these steps is explained in excruciating detail in the next four sections. None of the steps is at all difficult, but I have tried to include as much information as possible to head off the most common mistakes and questions that might arise. 6. STEP 1 - How do I set up the configuration file? The first step in the installation is to create the ZDCS.CFG file for your configuration. All of the ZDCS programs need this file. The location of ZDCS.CFG must be one of two places, according to the version of DOS you are using. If you are running under DOS 3.x or higher, this file should be located in the same directory as the ZDCS executable files. If you are running under DOS 2.x or lower, the configuration file should be located in the directory that will be the current directory when you run any of the ZDCS programs. Please note that I was not personally able to test ZDCS under DOS 2.x. If you have a problem under these versions, please let me know. The ZDCS.CFG file consists of seven short lines. (A sample is included in this package.) It takes far longer to read the description that follows than it does to write the configuration file from scratch. Line 1: The complete drive, path and filename of an ASCII text file that lists all the pathnames, one on each line, that contain the ZIPs to be included in the database. Note: This is how the DB module knows where to find the files that it has to process. If you are not using the index file feature in PCBoard 14.5A, then this is simply the DLPATH.LST file from PCBoard. Otherwise, you will have to create this file with a text editor. (Remember to add the trailing backslashes for each pathname.) There is no upper limit on the number of pathnames that can be processed. Line 2: The drive and pathname where the ZDCS database will be located. Note: A trailing backslash may or may not be supplied. The system will recognize it either way. Line 3: Either the letter "Y" or the letter "N". Note: This is where you set the switch to tell ZDCS whether to delete *all* duplicate files in the uploaded ZIP (Y) or leave them alone (N). Line 4: An integer (that's a whole number, no decimals) between 0 and 100. Note: This is the maximum percentage of files contained within the uploaded ZIP that may be duplicates of files already on your system. ZDCS will calculate the actual percentage of duplicates in the ZIP and compare it to your maximum percentage. If the actual percentage is lower, the uploaded ZIP is accepted. If the actual percentage is equal to or higher than the maximum you specified, the upload is declined. Line 5: The complete drive, path and filename for the log that will be created by the ZDCSFC16 program module. Note: This log will be an ASCII text file that contains information about the upload, such as: name of uploaded ZIP or GIF file; for a ZIP file, the breakdown of individual files inside it; notations for which files have been flagged as bbs ads or as duplicates already present on the system; the percentage of duplicates in the upload; and whether the upload was accepted or declined. If PCBOARD.SYS is in the current directory when the upload file checker is run, then the name of the currently logged caller is also included in the log file. Line 6: Either the letter "Y" or the letter "N". Note: This is where you set the switch to tell ZDCS whether to delete *designated* duplicate files (bbs ads) in the uploaded ZIP (Y) or leave them alone (N). Line 7: A single line of text selected by the sysop. Note: This text, without any quote marks, is appended to PCBFAIL.TXT whenever an upload fails the test for maximum percentage of duplicates. PCBoard displays this text message to the caller whose upload was declined, so the PCBoard @variables are supported here. It is recommended that the length of this line be limited to 72 characters or less. It must be at least one character long, even if that character is a blank space. An example message would be (without the quotes) "Too many duplicate files - upload must be reviewed by sysop." 7. STEP 2 - How do I create the initial database? The next step after creating the ZDCS.CFG file is to create the initial database of CRCs. The database consists of three files: ZDCS.NDX (the index), ZDCS.DAT (part 1 of the data) and ZDCS.PTH (part 2 of the data). There is a fourth file, ZDCS-DBB.LOG, which is an ASCII text file logging messages from the database creation process. For example, if a ZIP file had more than 675 individual files, this is where the message and the name of the file would be stored for the sysop to read. To create the database, you simply run the ZDCSDB16.EXE program. As long as you have created the ZDCS.CFG file properly, there is nothing more to be done until this program finishes processing. The display points out that you may press the F10 key at any time to abort. If you are not using a "front end" file integrity checker (like EXZIP) or if you are processing files from a CD-ROM, you might need to use the command "ZDCSDB16 T" to start the database build. The "T" will let ZDCS know to call PKUNZIP to test each ZIP and SFX file first. Anything that doesn't pass PKUNZIP is not processed by ZDCS, but is noted in the log file. This option slows the processing down tremendously! There is no need to use it on any directories that have passed a file integrity checker already. The ZDCSDB16 status summary contains both useful and esoteric information. One line in the middle of the screen will change frequently as files are being processed. Besides letting you know that the system is working, this line tells you something about the processing steps as they take place, just in case you were curious. The possibilities are: Directory C1 - ZDCS has just begun processing a new directory Directory C2 - ZDCS has just retrieved the next ZIP / SFX / GIF file within the same directory ZIP Directry - ZDCS is retrieving information from within an individual ZIP file SFX - ZDCS is retrieving information from within an individual SFX file ZIZ - ZDCS is processing a ZIP within a ZIP CRC - ZDCS is calculating the CRC-32 for a GIF file Indexing - ZDCS is writing the index and data to the Btree files Underneath this changing line is a line that tells you which ZIP, SFX or GIF file is currently being processed, with the full pathname included. Below that is the phrase "Member files" followed by the number of individual files within the ZIP, SFX or GIF being processed. (Remember, a GIF shows up as having only one member file.) The next line down starts with either "Share" or "NoShare" to indicate the type of "file opens" being used. The presence of the DOS share utility in memory is detected by all ZDCS programs to permit automatic use of the appropriate type of file access. The second item on the same line is the word "Files" followed by the number of ZIPs, SFXs and GIFs that have been processed so far. The third item on the same line is "Members" followed by the total of all the individual files that have been added to the CRC database so far. Since a GIF is thought of as a ZIP with only one file in it, each GIF that is processed is counted as just one more individual file here. The fourth item is "PDupes" followed by a number. This is arcane internal status information that will not be explained here. (Consider yourself lucky.) The very last line is the time of day when the ZDCSDB16 program was started. This time is taken from the DOS clock. Once the database build is complete, the end time will appear right after the start time on the same line. WARNING: If you start creating the database with ZDCSDB16 and then develop a sudden need to abort, use the F10 key! The display will remind you that F10 is the key provided for aborting the process. If you abort the program by any other method, you will almost certainly create lost and/or cross-linked clusters on your hard disk. It is entirely likely that when you first create the initial database you will already have some duplicate files in your collection of ZIPs and GIFs on the bbs. There is a small utility in this packaged called ZDCSDR16.EXE that will generate a list of all the duplicate files, sorted in ascending order by CRC. The list contains the CRC and the name of the duplicate file and the identity of the ZIP (with full drive and pathname) that contains the duplicate file. Output is to an ASCII text file named ZDCS-DUP.LST, which will be located in the directory that was current when the report generator (ZDCSDR16.EXE) was run. Use the F10 key if you change your mind and want to abort after having started the report. Note that no duplicate files are deleted by ZDCSDB16.EXE when you create the initial database. The list of duplicates, ZDCS-DUP.LST, can be used by the sysop to remove any duplicate files in the system. After the sysop has cleaned up the file system and removed any duplicate files, it is possible to purge duplicate entries from the database of CRCs. The advantage here is purely to reduce the size of that CRC database. ZDCS provides a way to do this purge, but first the sysop *must* make a backup of the database! This is very important. *Please* make a copy of the database and put it away somewhere safe before you start purging info from it. While it is always possible to rebuild the database, this takes a fair bit of time, especially for larger systems. And what sysop has enough time? To purge the database, type ZDCSDR16 P and hit the enter key. The "P" for purge will redirect the program to purging the duplicates instead of creating a report on them. This is not a fast process, but it will pay you back with a smaller database. 8. STEP 3 - How do I create the bbs ads database? This step is needed only if you have decided to use the option to delete designated duplicate files (usually bbs ads) from the uploaded ZIP. (GIFs are not affected.) To do this, you have to tell the system which files are the dreaded bbs ads by creating a bbs ads database. The database will be located in the same directory as the rest of the ZDCS files, and will consist of one file: ZDCS-BBA.NDX. The easiest way to do this is to first collect all those nasty ads together and zip them up into one ZIP file. Use whatever name you like for the ZIP; this example is going to call it BBS-ADS.ZIP. Then run the utility ZDCSBA16.EXE from the directory containing all the ZDCS files. The syntax (7% in NJ) is: ZDCSBA16 BBS-ADS.ZIP (If you have used a different name for your ZIP collection of bbs ads, just use that name in place of BBS-ADS.ZIP.) The program will create the database files and you will be ready to delete all that free advertising. Just make sure that you have used a "Y" as the next to last line of the configuration file to turn this option on. If you want to create a new bbs ads database in the future, just delete the old database file (ZDCS-BBA.NDX) and follow these same steps to create the new one. If you don't delete the old database, then the new ads will be added to the old ones in the database, which is an easy way to add new bbs ads. To make it even easier to include single ads as they come on the market, you can also run this utility on an individual bbs ad, whether it is zipped or unzipped. So, if a new bbs ad named HAPPY.BBS shows up, you can issue the command: ZDCSBA16 HAPPY.BBS This will add HAPPY.BBS directly to the bbs ads database. 9. STEP 4 - How do I set up the check for uploaded duplicates? Almost done! Now that you have created the ZDCS database(s), all you need to do is get the bbs to check all uploaded ZIPs and GIFs for duplicate files from now on. This will be done by processing the uploaded ZIPs and GIFs with ZDCSFC16.EXE when they are received. ZDCSFC16.EXE is the real-time upload tester that compares the CRCs of the files in the uploaded ZIP (or calculates them for an uploaded GIF) against the database(s). It also updates the duplicate files database (but not the bbs ads database) with the CRCs of the new files in the ZIP. To process the new uploads with this program, ZDCSFC16 must be called by the PCBTEST.BAT file (part of PCBoard) or by EXZTEST version 2.x. If using EXZTEST, simply rename ZDCSFC16.EXE to ZDCSFC.EXE and follow Andy's directions on using EXZTEST. A sample PCBTEST.BAT file is included in this package. (I know this configuration works, because I'm using it myself.) Here is that file, with lots of comments. The file statements are indented more than the comments, which begin with asterisks. @If Exist PCBFAIL.TXT Del PCBFAIL.TXT @If Exist PCBPASS.TXT Del PCBPASS.TXT @If Exist ZDCS-DEL.LST Del ZDCS-DEL.LST *** The file ZDCS-DEL.LST is created by ZDCSFC16.EXE if you are using either of the two options to delete duplicate files. It is a `control file' that is passed to PKZIP below. EXZTEST %1 0 %2 /@Q:\PCB\EXZIP.EXC /!r:\wrk\comment /s /w *** This command calls EXZTEST 1.x and lets it do its thing or things. ZDCSFC16 %1 %2 %3 *** These are three standard parameters passed by PCBoard code no earlier than version 14.5A from May 22, 1991. Earlier versions will provide only two parameters. The third one is absolutely *necessary* if you are going to allow pre-testing by your callers. Even if you don't want to let them pre-test, it does no harm to leave the third parameter in place. If Not Exist ZDCS-DEL.LST Goto End *** If neither of the "delete from zipfile" options is set to "Y", then you aren't deleting any files from inside the uploaded ZIP. In that case this file will not exist, so you obviously don't want to pass it to PKZIP. This bypasses the deletion. Pkzip -d %1 @ZDCS-DEL.LST *** This is where any duplicate files within the uploaded ZIP are removed from the uploaded file. :End *** That's all for PCBTEST.BAT, folks! In addition to creating the required PCBPASS.TXT and PCBFAIL.TXT files, ZDCSFC16 also sets the DOS error level when it exits. These levels are: 0 No duplicate files were found within the upload. 1 Some duplicates were found, but the upload passed the percentage test. 2 Too many duplicates were found, and the upload failed the percentage test. 3 Every file within the upload was a duplicate. 4 There is no number 4. (Reserved for future expansion.) 5 Upload checking by ZDCSFC16 was aborted. Please see log for error message. 10. PRE-TESTING - How can a caller get a jump on the system? Callers can pre-test an upload to find out how it compares to files already on the bbs in terms of duplicates and bbs ads. The idea is to see what ZDCS would say about the upload, before the on-line time and money are spent to actually upload the full file to the bbs. It can save both caller and sysop a certain amount of frustration. The procedure is wonderfully simple from a caller's point of view and requires nothing that might tax a relatively novice uploader's skills. There are no special files to download, no complicated operations to get right, no arcane rituals to perform. Included in this release of ZDCS is a sample bulletin that can be posted on the bbs to explain to callers what the pre-test feature is about for ZIP files. The bulletin holds their hands, figuratively speaking, through the whole process. If your bbs permits the uploading of SFX or GIF files, you might want to add those initials where you see ZIP in the bulletin. A ZIP- only bbs can use the canned bulletin right from the package. To pre-test an upload called GOODSTUF.ZIP, the caller simply issues the DOS command: PKZIP -V GOODSTUF.ZIP > ZDCSTEST.CHK This command is not case sensitive, so it's pretty hard to make a mistake with it. The caller then uploads the file ZDCSTEST.CHK directly to the bbs. ZDCS will read the information in it and will give the caller a breakdown of the ZIP file's contents, noting which individual files are duplicates or bbs ads. This output looks just like the response a caller gets after actually uploading the ZIP file, with one exception: instead of telling the caller whether the file is accepted or declined, ZDCS tells the caller what percentage of files in the upload are duplicates, and also gives the maximum percent duplicates allowed for the board. (This is configured by the sysop to some whole number way back in section 6, remember?) Now it's up to the caller to decide whether to upload or not. Enabling the pre-test capability is not tough on the sysop, either. The key to whether or not pre-testing is permitted on your bbs lies in the UPSEC file. If you want to prevent callers from using pre-testing, just disallow uploads that have the .CHK extension. On the other hand, if you want callers to have the option to pre-test, make sure that .CHK files may be uploaded to the system. What else does the sysop have to do? Make sure that the PCBTEST.BAT file contains the following line: ZDCSFC16 %1 %2 %3 This was already discussed in section 9, where it was pointed out that the third parameter is critical to a well-behaved pre-test capability. If you inadvertently leave out the third parameter, the pre-test will work just fine for the first caller and will barf all over subsequent callers, who will come complaining to you that their ZDCSTEST.CHK is being called a duplicate! If you track your callers' uploads and downloads, you might like to know that the ZDCSTEST.CHK will not count as an upload. According to ZDCS and PCBoard, the ZDCSTEST.CHK file always "fails" validation and is not credited to the caller as an upload. The bulletin does mention that pre-testing doesn't count as an upload, just in case some of your callers are *too* enthusiastic. One important thing needs to be noted about the PCBoard software and pre- testing: your board code must be no earlier than PCBoard version 14.5A from May 22, 1991. 11. LIMITS AND FUTURE ENHANCEMENTS - What else should I know? As released in version 1.6, ZDCSFC16 requires a little less than 115K, plus whatever overhead PKUNZIP requires for processing ZIPs within ZIPs. There is an internal limit of 675 files within an individual ZIP that can be processed during the database build (ZDCSDB16.EXE). For the upload file checker (ZDCSFC16.EXE), the limit is 425 files within an individual ZIP. If you process a ZIP file with more than the limit of files, ZDCS will process the first 675 files in the database build or the first 425 files in the upload file check, then it will leave a message in the log file. There is nothing to reset and no effect on processing the next file ZDCS encounters. These limits are imposed by the DOS 640K Limit. Processing of ZIP files contained within ZIP files is accomplished with some caveats. ZIPs within a ZIP are only checked one level deep. The simplest explanation I can think of is an example. ZIP A contains assorted files and ZIP B. In turn, ZIP B contains more files and another ZIP, C. ZIP C contains still more files. How does the whole melange get processed? All the files in ZIP A and in ZIP B have their CRCs entered into the duplicate files database. If you have selected to delete either *all* duplicates or *designated* (bbs ads) duplicates, then those deletions are done automatically only for the files in ZIP A. Of course, all the duplicates in ZIP B are still listed in the log, so you do know about them and you can decide whether to remove them manually from your file system. What about ZIP C? That's easy: any ZIP embedded more than one level deep in the uploaded ZIP (and C is two levels deep) is not processed as a ZIP at all. No file deletions, no CRCs, nothing. In fact, any file that has the .ZIP extension will not be mentioned in the database or the log file. The reason is simple: it's the *individual files* inside the ZIP files and not the ZIP itself that is important when looking at duplicates. Besides, it plays havoc with the percentages. There is one way to delete ZDCS database records: purging the database using ZDCSDR16 P. This was discussed at the end of section 7. Let me just remind you to make sure you have finished cleaning out the duplicates from your file system and to make a backup of the database anyway before you purge the database! 12. REVISION HISTORY - What's happened since version 1.00? Release 1.60: Version 1.60 adds the capability to handle self-extracting EXE files created with PKSFX (SFX), and "other" files like GIFs. There has been a substantial increase in the processing speed so that now all files are processed about three times as fast as they were under version 1.5x. As an example, I ran ZDCS on a 10MBS LAN (where the disk reads across the LAN were a speed bottleneck) and it processed 80,894 individual member files within 4,734 ZIPs, SFXs and GIFs in 2 hours and 25 minutes. Your mileage may vary. A pre-test capability has been added to permit bbs callers to pre-test a ZIP, SFX or GIF file for duplicates before spending the time to upload the full file to the board. This capability does not require the caller to download any special programs or perform any complicated operations. A database purge facility has been added to reduce the size of the CRC database *after* the reported duplicates have been cleared from the file system. The maximum number of files within a ZIP that can be processed by ZDCS is set at 675 for the database build and 425 for the upload file check. Note: In order to raise these limits, I will either have to make EMS a requirement for running ZDCS, or I will have to slow down the processing by writing temporary files to disk. Please let me know how you feel about this, and whether it would be worth it to you to see a future version of ZDCS use one of these methods to raise the limits. The sysop has been given the opportunity in version 1.60 to set a text message that will be displayed to callers when an upload has been declined. Release 1.60 also incorporates an interface to third party applications, which has been implemented for EXZIP and EXZTEST. If you are interested in writing an application to interface with ZDCS, please drop me a note for the technical info on the interface. What was previously available in version 1.5 as a rudimentary test mode has been heavily modified to permit the creation of the interface to third party applications. The old test mode is no longer available - the guts of it were used to provide a seamless integration with EXZTEST / EXZIP. Release 1.5x: In version 1.5 the database builder ZDCSDB15.EXE now correctly handles ZIP files stored *with paths* within ZIP files. The previous internal limit of 99 pathnames has been increased to 999. Where the existence of an empty subdirectory among the pathnames caused the earlier database builder to abort, ZDCSDB15.EXE can now handle an empty subdirectory. The real-time upload checker ZDCSFC15.EXE now correctly handles ZIP files stored *with paths* within ZIP files. Previously, a file listed in the bbs ads database could still be considered a duplicate file, which affected the "percentage of new files" calculation for an uploaded ZIP. The bbs ads are no longer counted as duplicates when determining the percentage of new files in the upload. The database structures used in ZDCS 1.00 have been redesigned for version 1.5 to cut down on the database size. At the expense of a little speed, the database is now slightly less than half the size it used to be. The new option of "allowed duplicates" has been added in version 1.50. This is so that files like OMBUDSMN.ASP and VALIDATE.DOC needn't be counted as duplicate uploads. The allowed duplicate files may be designated by either filename or by CRC. A new test mode has been added for the operation of the upload file checker, ZDCSFC15.EXE. If the word TEST is used instead of the word UPLOAD as the second parameter passed to ZDCSFC15, then the upload checker can be used to test a specific file for duplicates without causing any updates to be written to the database or the logfile and without creating PCBPASS.TXT or PCBFAIL.TXT. Test results will be written to ZDCS-TST.OUT. The easiest and safest way to run such a test on any ZIP file FOO.ZIP is to issue the command to test the files within the ZIP file FOO.ZIP. I don't expect most sysops to need this capability, but it's available. There have been numerous beta versions of ZDCS between release 1.00 and release 1.50. Conversion programs for the database information from those beta versions to the new version 1.50 format are available on The Hacker Central BBS. Please see the next section for further information about ZDCS support on The Hacker Central. 13. REGISTRATION AND SUPPORT - How do I get help? I'm afraid that I am going to have to break one of my own rules with this release. As a sysop myself, I have long been of the opinion that sysops are going broke fast enough without my help, and have consequently released all of my sysop utilities as freeware. With the amount of time and effort that has gone into ZDCS and the level of support I have been offering, the ZDCS package has been released as shareware. ZDCS is a fully functional shareware package. There are no critical limits, crippled features or "drop dead" dates. The only difference is a brief message to sysop and caller that the version is unregistered. If you try ZDCS out on your system and decide that you want to continue using it, please register your copy by sending a check for $25.00 (US). Include the name of your bbs (up to 25 characters) as you want it to appear to your callers. We will prepare a key file for your copy of ZDCS with this information in it to replace the "unregistered version" line in the display. This keyfile will be available for download from The Hacker Central BBS. Registration entitles you to a license for use of the Zipfile Duplicate Checking System on one bbs, including all future versions of ZDCS. No additional fees will be charged for registration of future versions of this product. Please make your registration check payable to Michael W. Cocke and mail to: Michael W. Cocke 11 Cedar Road Montville NJ 07045-9582 Please be assured that I will continue to support ZDCS through future revisions. I have been using it on our own bbs, The Hacker Central, and wonder how I lasted so long without it. Product support will be handled two ways. Questions and discussion of ZDCS are welcome in the ILink SHAREWARE conference, available through most ILink member bbs's. Product support will also be done on our home bbs, The Hacker Central. Please call us on our public node 1: 201-334-2555 N81 1200-2400 baud. Callers are usually validated within 24 hours and all users of ZDCS will be given access to the high speed node 2: 201-318-8840 N81 1200-38,400 HST/v.32. A special conference is available for all users of ZDCS. (Suggestions and requests cheerfully welcomed.) From time to time, special utilities and support modules may be released to help folks with specific needs related to ZDCS. For example, a module to convert from the FWKCS(tm) database to the ZDCS database is in testing right now. This module enables one to convert the data in the database without having the original source files easily available. Another module that is under consideration would be to ferret out instances of bbs ads that might have crept into the database before the sysop realized they were bbs ads and put them under interdiction. Other utilities that have already been released were to help convert from earlier versions of ZDCS, as described below. All of these files are available directly from The Hacker Central BBS. If you have a beta copy of ZDCS 1.5 (dated before March 30, 1991), you can simplify conversion to the release version of ZDCS 1.5 or to this release 1.6 with the following utilities, all on The Hacker Central BBS: ZDCSO2N.EXE Database format converter to change over from version 1.0 to version 1.5. ZDCSL2N.EXE Database format converter to change over from version 1.5L (a beta version) to version 1.5. ZDCSRK15.EXE Index key regenerator to change over from any beta versions except 1.5L to version 1.5. ZDCS may be freely copied and distributed, provided that it is distributed in its complete and original form with all individual files intact and unmodified. No fee of any kind may be charged for distribution or copying of the ZDCS package. 14. ACKNOWLEDGEMENTS - Thank you! I'd like to thank all my beta testers for their patience and their input to ZDCS. Their help has made ZDCS a better and smoother program for both sysops and bbs callers. I'd especially like to thank my wife, Evelyne Stalzer. She's the one responsible for turning my explanations, comments, hieroglyphics and muttered imprecations into English documentation. 15. COPYRIGHTS AND LEGAL STUFF - What do the lawyers want to see? Michael W. Cocke and MWC Enterprises will not accept responsibility for the function, failure to function, or side effects of any function of the Zipfile Duplicate Checking System (ZDCS). ZDCS is provided in good faith, but its use is *solely* at the risk of the operator. EXZTEST and EXZIP are copyright Andy Keeves. FWKSC is trademark and copyright Fred Kantor. Lantastic is trademark of ArtiSoft Inc. MS-DOS is copyright and trademark of Microsoft Corp. Novell is trademark of Novell Inc. PCBoard is copyright and trademark of Clark Development Company. PKZIP and PKUNZIP are copyright and trademark of PKWARE, Inc. Wildcat! is copyright Mustang Software. ZDCS is copyright (C) 1991, Michael W. Cocke.