ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

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

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / BBS / DOORS / XFD_V203.ZIP / XFDDOCEN.DOC < prev

Wrap

Text File | 1991-08-23 | 125.1 KB | 2,579 lines

╔══════════════════════════════ ┌─────────────────┐ ║ XFD │ D.I.S.P. │────┐ ║ FileDoor (tm) │ │░░░░│ ╟────────────────────────────── │ │░░░░│ ║ (c) 1991 Robert W.van Hoeven │ Dutch │░░░░│ ╟────────────────────────────── │ Independent │░░░░│ ║ Release : 2.03 │ ShareWare │░░░░│ ║ Rel.Date: 23th August 1991 │ Programmer│░░░░│ ╠══════════════════════════════ └─────────────────┘░░░░│ ║ Documentation | │░░░░░░░░░░░░░░░░░│ ║ (c) 1991 Reinier E.B. de Groot | └─────────────────┘ ║ (c) 1991 Robert W. van Hoeven | ┌─────┐ | ║ | │░░░░░│ | ║ | └──┬──┘ | ║ Changes to version 2.02 are | ┌────┴────┐ | ║ marked with '│' in front of ------││││││ ═══│------- ║ the text. └─────────┘ ╠═══════════════════════════════ ║ Address: Robert W. van Hoeven ║ PO. Box 131 ║ 1170 AC Badhoevedorp ║ Nederland / Holland ╚═══════════════════════════════ ┌───────┬─────────────────────────────────────────────────────────────┐ │ 0 │ Table of contents │ └───────┴─────────────────────────────────────────────────────────────┘ 1 ---- General information 1.1 Copyrights and License Agreement 1.2 Newer versions and contacting the author 2 ---- Package description and requirements 2.1 Preface 2.2 Requirements 2.3 Included files 2.4 History 2.5 Introduction & specs 3 ---- Installation description 3.1 Installation (general) 3.2 Installing FILEDOOR.EXE 3.2.1 Downloads 3.2.2 Uploads 3.2.3 Bidirectional 3.3 FILEDOOR.CFG │ 3.3.1 Very special statements │ 3.3.2 Basic statements │ 3.3.3 Statements that define the environment that FILEDOOR uses │ (paths) │ 3.3.4 Statements that define the logging-format │ 3.3.5 Other statements, not related to protocol definition │ 3.3.6 Filedoor's Protocol Definition 3.4 FD_UPD and FILEDOOR.UPD 4 ---- Runtime information 4.1 Command-line switches 4.2 Fast Modems 4.3 Multiline operations 4.4 Swapping 4.5 FileDoor/DISP-compatible tag-file <tm> 4.6 Fileselection 5 ---- Version information and credits 5.1 The BETA-team 5.2 Credits 5.3 Version history 5.4 Copyright, Trademarks ┌───────┬─────────────────────────────────────────────────────────────┐ │ 1 │ General information │ └───────┴─────────────────────────────────────────────────────────────┘ 1.1 Copyrights and License Agreement ──────────────────────────────────── - Users of the FileDoor-package must accept this disclaimer of warranty: - The FileDoor-package is supplied as is. The author disclaims all warranties, expressed or implied, including, without limitation, the warranties of merchantability and of fitness for any purpose. The author assumes no liability for damages, direct or consequential, which may result from the use of the FileDoor-package; - The FileDoor-Package is a "shareware program" and is provided at no charge to the user for evaluation. Feel free to share it with your friends, but please do not give it away altered or as part of another system. The essence of "user-supported" software is to provide personal computer users with quality software without high prices, and yet to provide incentive for programmers to continue to develop new products. - If you find this program useful and find that you are using and continue the use of the FileDoor-package after a 30 days trial period, you must register the FileDoor-package as described below; - Send a postcard to Robert W. van Hoeven, with your address, net/node number and 'FileDoor v2.01 registration' on it. The exact address is in the header of this documentation; - Anyone distributing the FileDoor-Package for any kind of remuneration must first contact the Author at the address above for authorization; - You are encouraged to pass a copy of the FileDoor-package along to your friends for evaluation. Please encourage them to register their copy if they find that they can use it; - Support on FileDoor is available by means of written letters or by entering the international echomail area DISP (available on the Echomail backbones of FidoNet <tm> in every zone); - Problems and suggestions can be entered in the FidoNet <tm> Echomail conference <tm> called DISP (international). Entering this echo does not exclude you of the duty to register the FileDoor-package, though users who evaluate the product can enter the echo for questions; - The FileDoor-package, all programs excluding the documentation, are now copyrighted 1991 by Robert W. van Hoeven, PO. Box 131, Badhoevedorp 1170AC, Holland. The original idea and realization is copyrighted 1988-90 by Stig Jacobsen, DAK Software. │ The documentation is copyrighted 1991 by Reinier E.B. de Groot and │ Robert W. van Hoeven; - All rights are reserved. You may copy this package for backup purposes. Also you may copy and share unmodified copies of the whole package, providing that the copyright notice is reproduced and included on all copies. Excluded from this statement are the support-files written by other authors. Please refer to the documentation of these programs for copyrights and license agreements; - It is forbidden to modify, adapt, translate, reverse engineer, de- compile and/or disassemble the software in the FileDoor-package. Patching the medium at places that carry the software is seen as a program change and is also forbidden; - Performing any of the illegal actions as stated in the previous lines, is a theft and no fair play to the author and, more important, to the registered users; - Bulletin Board Systems that distribute the FileDoor package can convert the WHOLE package to any archive-system they like but all original files must be included in the new archive. The FileDoor-package on the Bulletin Board can contain at the most 2 extra files. These files can only be a commercial for that Bulletin Board and/or validation data that is presented as a service to all users and shall have no other functions; - After the normal trial period of 30 days, you must register the soft- ware (see REGISTER.XFD) or you must remove it from your PC; - Comments, suggestions and bug reports are welcome and will be answered as soon I have the time to do so. You can send me a letter of leave a NetMail <tm> message named to Rob Van.hoeven (mind the point) on node 2:512/100 (RA Support, Monster, Holland, SysOp is Reinier de Groot). When you want to send me normal mail, address it to: Robert W. van Hoeven, PO. Box 131, 1171 AC Badhoevedorp, Holland; Also you can enter messages in the FidoNet <tm> DISP Echomail <tm> area; 1.2 Newer versions and contacting the author ──────────────────────────────────────────────────────────────────────── The newest version of FileDoor is always available at the DISP-HQ on node 2:512/100. FileDoor is also distributed thru a number of DISP support nodes. You can obtain FileDoor in four different ways: - Logging on at DISP-HQ or a support node All zones : 2:512/100 (Multiline Paradise NL #1) DISP-HQ (Sysop: Reinier de Groot ) 2:512/129 (MultiLine Paradise NL #2) DISP-HQ (Sysop: Reinier de Groot ) For zone 1: 1:203/988 (Amber Shadow USA ) Support & beta (Sysop: Dave Overton ) (The Chess Board USA ) Support & beta (Sysop: Ken Givens ) For zone 2: 2:280/216 (Sirex NL ) Support & beta (Sysop: Gerry Ulrich ) 2:242/4 (GOLEM Meerbusch FRG ) Support & beta (Sysop: Hanstheo Wolf ) 2:241/5603 (FunBoard Felbert FRG ) Support & beta (Sysop: Dirk Astrath ) 2:244/8500 (Nilpferd BBS FRG ) Support & beta (Sysop: Joerg Dassler ) 2:403/139 (The Black Universe ISR ) Support & beta (Sysop: Saar Blitz & ) ( Addy Santos ) 2:405/166 (Hith Hiker BBS ISR ) Support & beta (Sysop: Alon Gingold ) 2:200/407 (Secret Blue Valley SWE ) Support & beta (Sysop: Andreas Birgerson) 2:257/168 (Barnabas the Caring UK ) Support & beta (Sysop: John Barton ) 2:440/63 (Frontiers BBS UK ) Support & beta (Sysop: Dave Parker ) 2:233/0 (REC_Italy ITL ) Support & beta (Sysop: Stefano Pasquini ) 2:512/116 (The Cavern BBS NL ) Support & beta (Sysop: Victor Warning ) 2:292/600 (Tornado Belgium B ) Support & beta (Sysop: Frank v. Uffelen ) For zone 3,4,5 and 6 (vacant or pending ) The BBS's above will always have the most current version of FileDoor available. Also, in some cases, it is possible to request the newest FileDoor with a standard file-request (ask the SysOp in question). On 2:512/100 you can use XFDNEW as magical name to Freq. the newest version. The actual DISP-HQ is point 2:512/100.5, but this is a closed system and can not be accessed from the 'outside'). You CAN address netmail to this point though ! - Logging on to a SDS node FileDoor is distributed thru SDS/SDN, but only big minors (x.10, x.20 and so on) and majors (2.01, 3.01 and so on) are submitted to the SDS distribution point in Holland; - Logging on to your own favorite and local BBS; Chances are, that you will find an older version (international users) because it will take some time for the new version to 'bleed' thru the net; If you think you have found problems in FileDoor, or in any other case, you wish to contact the author, you can send me: - A letter to the address you can find in the header of this file; - A NetMail <tm> message to Rob Van.hoeven (please mind the dot between Van and Hoeven) at 2:512/100 or (better) 2:512/100.5; - A Message in the FidoNet <tm> DISP echomail <tm> area; WARNING : When you submit messages by NetMail you must agree to a few rules: - Besides the DISP echomail area I frequently look into all Remote Access <tm> echomail areas but NOT in QuickBBS/SBBS area's. You must submit any echomail messages in DISP (is preferred) or in the RA_UTIL area. Messages in other echo- mail area's could never be read by me; - When you find any errors or have any suggestions, you must DIRECTLY address the message to me (Rob van.hoeven, mind the point). Messages with 'subject' set to 'FDBUG: some thing' or 'FDSUG: something' are always catched by me first so use that subject in your message; - Netmail messages must be send to FidoNet 2:512/100.5 (direct) or 2:512/100 (indirect) and must also contain the correct name (Rob van.hoeven); ┌───────┬─────────────────────────────────────────────────────────────┐ │ 2 │ Package description and requirements │ └───────┴─────────────────────────────────────────────────────────────┘ 2.1 Preface ──────────────────────────────────────────────────────────────────────── Please notice the following: - FileDoor is a ShareWare product in every right way, this means this software is not crippled in any way. Also FileDoor is FREE ! Only a postcard and some stamps are needed to register FileDoor; Everyone is urged to register the program when using it for a period longer than 30 days. - This program will need the actual protocol drivers to work. These are not supplied in this package, but are widely available on most BBS's. Therefor please contact the author of the protocol driver when you have problems with the driver. You may contact the author of FileDoor or one of the support boards when you have a question on how to install a certain file-transfer protocol in FileDoor. - If you have created a working example in FileDoor.CFG for a new type of protocol, I would like it very much if you send me a copy of the actual PROTOCOL-statement. With newer releases, other can benefit from this knowledge. Your name will be added to the 'what's new' list at the bottom; 2.2 Requirements ──────────────────────────────────────────────────────────────────────── FileDoor - PC XT/AT/386 - At least 280K free memory for FileDoor to run. Some extra kB's are added for each file you select. Extra memory requirements are depending on the selected protocol driver. - DOS 3.xx and higher; (tested with 4Dos 3.03, should work with lower versions); 2.3 Included files ──────────────────────────────────────────────────────────────────────── The package includes : FILEDOOR.EXE The main program FILEDOOR.CFG An example config file │ BIMODEM.CFG An example of Bimodem.CFG XFD.NEW What is new in current version XFDDOCEN.DOC The documentation REGISTER.XFD Registration information REG_FORM.XFD Registration form VENDOR.XFD Vendor information README.1ST Last minute information *.ANS Example of ANSI-menu/Help files *.ASC Example of ASCII-menu/Help files 2.4 History (by Reinier de Groot) ──────────────────────────────────────────────────────────────────────── FileDoor <tm> is an original product from Stig Jacobsen. His program is a widely used protocol driver on many BBS's in all zones and nets. The last version (v1.21) was released in 1989 and since then implemented in many QuickBBS and Remote Access BBS systems (the last be means of some tricks to fool Remote Access and FileDoor). All rights of FileDoor and the complete source code were transferred to Rob van Hoeven in the late 1990. Because of his work and many other activities Stig was not able to release a much wanted updated version for the currently supported BBS systems and the newer ones. In the beginning Rob started to work with the original source code. For several reasons this method was abandoned and Rob decided to write a completely new version from scratch. This way he could use all his experience with Turbo Pascal (his second native language) and all available commercial toolboxes. To accommodate the user with the fastest performance that is possible in Pascal (Pascal implementations are always use somewhat more memory and are somewhat slower than C implementations) a number of registered com- mercial toolboxes are used to gain in speed and to reduce the memory. A complete list of the used products is found at the end of the document. The current version of FileDoor is a complete rewrite and extends file-transfer options of many BBS programs to a State Of The Art! The tradeoff is a bigger memory consumption. There are several options in FileDoor 2.xx that were not available before and all these options will cost some memory. Rob saw no problems in extending the memory usage be- cause most BBS programs now have a swap-option in their external calls (like the type 7 *M option) and for those BBS's that don't have these options, FileDoor itself can also swap before a protocol is called. It should also be noticed that all ORIGINAL functions of FileDoor still │are (and will stay) in the program. The benifit is, that you can easy │upgrade to a newer version, the tradeoff is that the basic point of │few can not be altered. Though Rob is CoSysop on my system and has done work as a Sysop on his own systems for several years, he is also works as a BBS-user. As you │will see, much is changed in the interface to the user. The interface │will benifit both the 'normal' user and the 'sysop as a user' who will │see her/his work reduced to some keystrokes. The current version you own (XFD_V203) will work for QuickBBS, Remote Access, SuperBBS and compatible clones. A separate package will be available soon (OFD_V201) that will interface to OPUS, Maximus and │compatible clones. BBS programs that have a newer beta-version will │(sometimes) not work if the internal structures are changed. There is │only direct access to Remote Access's <tm> beta versions and most of │the time, FileDoor will be able to work with the newer beta versions │of this program. 2.5 Introduction & specs ──────────────────────────────────────────────────────────────────────── FileDoor is an interface to hook external file-transfer programs into RemoteAcces, QuickBBS and SBBS or compatible clones of these systems. FileDoor will add features and flexibility to transferring files, which will not be found in any BBS or file-transfer interface. FileDoor has: - an interface to RemoteAccess, QuickBBS and SuperBBS systems. Remote Access 0.xx and 1.xx are both supported as are the QuickBBS 2.xx and SBBS 1.1x types; - full security support, including security levels and flags of the above mentioned BBS programs. - support for the FILES.RA/FLSEARCH.CTL file. - support for LIMITS.CTL - full multinode, multitasking capabilities. │- support for many (255) external file-transfer protocols, including │ those producing a DSZLog alike LOG file. - Built-in Fossil support. - support for Bidirectional transfer protocols (only Bimodem at the moment). - support for CD-ROM systems when implemented in the BBS. - Filecounter ( [xx]) support. - user ratio monitoring. - direct updating in the BBS, if supported by the BBS. - support for external help and menu files. - ultra fast AutoSearch with in-archive file-view options. - an option to refuse 'unwanted' files. (*.GIF, PKZ110.EXE etc). - configurable download hours. - extended and userfriendly interface to select files for transfer. - macro support! - several exit points for third party products. - a direct interface for semi-auto-download with the FileDoor/DISP compatible tag-file options. │- Retaining the same easy interface for (the much forgotten) ASCII │ user group; - all those options not found in most BBS program or any other transfer interface. 2.6 Thoughts on FileDoor (by Rob van Hoeven) ──────────────────────────────────────────────────────────────────────── I would like a moment of your time to share with you the ideas I have about FileDoor and doors in general. When I took over FileDoor from Stig I still found it the most usefull door ever written for QBBS/SBBS/RA BBS systems. It was easy to work with, worked almost perfect and was rather fast. The deal I made with Stig was that I should not alter the basic idea of the program. I knew that in advance and agreed on this ! The FileDoor you see before you has still the same functional skeleton as the older 1.21 (Stig's last version). Some new functions are build AROUND this skeleton but do not replace it. My general idea of doors is much the same as you see in FileDoor. I think that a door should be designed to complement a BBS's internal feature or replace it with something much better. What I try not to do is to think for the user. In my opinion it is much better to have 4 doors, each complementing each other, with each bringing the best there is, than to have 1 general door that can do everything. Unless very well written, those doors will not give you the best of ALL the functions or are better in some and lesser in other. Also, such doors can better be converted to a BBS program itself because they force you only to use the BBS program as a skeleton and not as a BBS. If this is the case in your implementation, you should allow yourself to recon- sider if you run the right BBS program for your taste. Given this (personal) idea, I make doors that can complement each other (like FileDoor, MTS and RFW) but still leave you free to replace one or more with a door that is more to your taste (eg. replace RFW with something else and still getting the best from MTS and FileDoor). The main goal is to leave the choice to you and not to the program. Given this info, I don't have any problems with 'compatible' doors and certainly not when they fit more into your own BBS-environment. If there is a GENERAL demand for specific new features, they will be im- plemented in FileDoor. If I find something of interrest myself, I al- so will consider to implement it. So the future of FileDoor is up to you. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 3 │ Installation description │ └───────┴─────────────────────────────────────────────────────────────┘ 3.1 Installation (general) ──────────────────────────────────────────────────────────────────────── │Before installing you MUST read this DOC file and the README.XFD file, which will contain last minute addendum (when present). Installing FileDoor is quite simple assuming you have read the DOC file. First read the part on how to install FileDoor.Exe in your BBS system, then carefully read the part about the configuration file (FileDoor.Cfg). When you take the time to read every possible option while creating the control-file you will see that everything is not that difficult at all and you can get the most out of FileDoor. If you still have problems, you could enter a message in the FidoNet DISP Echomail area. - Place FILEDOOR.EXE and FILEDOOR.CFG in some directory in the DOS PATH. If you run DOS 3.xx you can also use a directory that is not inside the DOS-path; - Create a FILEDOOR.CFG file in the same directory (see instructions) or the directory that FILEDOOR.EXE is called from (DOS 3.xx and higher). It is wise to create a FILEDOOR.CFG for every BBS line you have on your system (if you run a multi-line BBS); - Take special care with memory requirements (see later); - Be sure to set DSZLOG to a valid directory and filename (for each line a separate file or separate directory). Read 4.3 in case of doubt !! FileDoor.CFG can be found in the following ways: - -C[drive:][\path\][filename] on the type 7/15 menu commandline; - In the current directory, the directory FileDoor.EXE was executed from or the path (in that order); - From an environment variable: Use SET FILEDOOR=[drive][\path\] to show the directory where FileDoor.CFG is located (don't forget the trailing backslash) USE SET FILEDOOR=[drive][\path\][filename] to show path and file to use as configuration file; 3.2 Installing FILEDOOR.EXE ──────────────────────────────────────────────────────────────────────── The program is installed as a type 7 (shell to file) or type 15 (exit to DOS) in your RemoteAccess/QuickBBS/SuperBBS menu. Although a type 7 exit is faster and much easier to install, it will use more memory. So depending on your hardware you must either choose for a type 7 or a type 15 exit. Both the DORINFOx.DEF and EXITINFO.BBS file are supported by FileDoor. Depending on your hardware limitations you may also use the swap-to-memory or disk option of your specific BBS program. IMPORTANT: This version of FileDoor uses the DSZLOG environment variable and does not set one itself. So please, use a different SET DSZLOG=xxxx for each seperate line you run !!!!!!!!!! Command-line switches: o -DD, Do Download; o -DU, Do Upload; o -DB, Do Bidirectional transfer; o -A[path] to be used as the download path. Not necessary when you use AutoSearch in FileDoor.CFG; o -N[line] for the BBS line number (defaults to 1). Not necessary when │ you use BBSLine in FileDoor.CFG. Some implementations of the Remote │ Access BBS allow the use of *N in the type-7 parameter only once ! │ It is advised to use the -CFILEDOOR.CF*N option to select the type │ of CFG-file and to use the BBSLine option inside these separate │ FILEDOOR.CF? files !!! o -U[path] to be used as the upload path. Not necessary if UploadPath is used in the FileDoor.Cfg; o -P[path] to be used as the upload path for private uploads. This switch is not needed if PUploadPath is used in FileDoor.CFG or if there is no need for a special path for private uploads; o -C[cfg] to call another FILEDOOR.CFG. Useful when running a multinode setup. This way each line has it's own configuration. See the chapter on multiline operations; 3.2.1 Download ──────────────────────────────────────────────────────────────────────── When installing FILEDOOR.EXE for downloads in RemoteAccess/QuickBBS/ SuperBBS as a type 7 exit, the optional datafield should at least contain the following: │[Drive:\Path\]FILEDOOR.EXE -DD -A[DownloadPath] -C[cfg file] The -A switch may be omitted when you have the AutoSearch feature en- abled. FileDoor will use all BBS program specific files like FILES.RA in RemoteAccess environment to do security locking. As mentioned before you may also use the switch to swap your BBS program for a large part to EMS/Disk. Example for RemoteAccess: │FILEDOOR.EXE -DD -CFILEDOOR.CF*N -AC:\BBS\FILES\DISP *M │ │The *N option will be used to select between different FILEDOOR.CF? │files for the different lines. *M is used to swap the largest part │Remote Access to EMS/Disk. When you run a single-line BBS, you can │leave out the *N and use -CFILEDOOR.CFG. IMPORTANT: SuperBBS users MUST use the *E options both for a type 7 and a type 15 exit to reload the EXITINFO information back to the BBS; When you use a type 15 exit then you must change your batch file in such a way that after exiting with an errorlevel you jump to the routine that will start FILEDOOR.EXE. This way you MUST supply all parameters on the command-line. Also the usage of -R is advised as it will reload the information from EXITINFO.BBS back to the BBS. 3.2.2 Upload ──────────────────────────────────────────────────────────────────────── When installing FILEDOOR.EXE for uploads in RemoteAccess/QuickBBS/ SuperBBS as a type 7 exit, the optional datafield should at least contain the following: │[Drive:\Path\]FILEDOOR.EXE -DU -U[UploadPath] -C[cfg file] │ │The -U switch may be omitted when you use 'UploadPath' in FILEDOOR.CFG. FileDoor will use all BBS program specific files like FILES.RA in the Remote Access environment to do security locking. Also for the uploads you may use the appropriate switch to swap your BBS program for a large part to EMS/Disk. Example for RemoteAccess: │FILEDOOR.EXE -DU -CFILEDOOR.CF*N -UC:\BBS\FILES\DISP *M │ │The *N option will be used to select between different FILEDOOR.CF? │files for the different lines. *M is used to swap the largest part │Remote Access to EMS/Disk. When you run a single-line BBS, you can │leave out the *N and use -CFILEDOOR.CFG. IMPORTANT: SuperBBS users MUST use the *E options both for a type 7 and a type 15 exit. When you use a type 15 exit then you must change your batch file in such a way that after exiting with an errorlevel you jump to the routine that will start FILEDOOR.EXE. This way you MUST supply all parameters on the command-line. Also the usage of -R is advised as it will reload the information from EXITINFO.BBS back to the BBS. 3.2.3 BiDirectional ──────────────────────────────────────────────────────────────────────── When installing FILEDOOR.EXE for bidirectional transfers in RemoteAccess, QuickBBS or SuperBBS as a type 7 exit, the optional datafield should at least contain the following: │[Drive:\Path\]FILEDOOR.EXE -DB -U[UploadPath] -A[DownloadPath] -C[cfg] │ │The -A switch may be omitted when you have the AutoSearch feature │enabled. The same goes for -U when you have the UploadPath option set │in FileDoor.CF?. FileDoor will use all BBS program specific files like FILES.RA in the Remote Access environment to do security locking. As mentioned before you may also use the switch to swap your BBS program for a large part to EMS/Disk. Example for RemoteAccess: FILEDOOR.EXE -DB -CFILEDOOR.CF*N *M (AutoSearch enabled and UploadPath in Filedoor.Cfg) │The *N option will be used to select between different FILEDOOR.CF? │files for the different lines. *M is used to swap the largest part │Remote Access to EMS/Disk. When you run a single-line BBS, you can │leave out the *N and use -CFILEDOOR.CFG. IMPORTANT: SuperBBS users MUST use the *E options both for a type 7 and a type 15 exit. When you use a type 15 exit then you must change your batch file in such a way that after exiting with an errorlevel you jump to the routine that will start FILEDOOR.EXE. This way you MUST supply all parameters on the command-line. Also the usage of -R is advised as it will reload the information from EXITINFO.BBS back to the BBS. 3.3 FILEDOOR.CFG ──────────────────────────────────────────────────────────────────────── The FILEDOOR.CFG file is a normal text-file (ASCII-file). You can create this file with program's like EDLIN or any other ASCII-editor. FILEDOOR.CFG must be in the DOS-path (DOS 2.xx) or in the same directory that FILEDOOR.EXE is called from (DOS 3.xx or higher). For multi-line operations it is advised to use a FileDoor.CFG for every line you run (see the chapter about multiline operations). FILEDOOR.CFG contains many options. Some of them optional, some of them not. The general format for the FILEDOOR.CFG file is: Option {parameter} {parameter} ..... {parameter} There are NO restrictions to the position you start the command, nor the starting position of the (optional) parameters, but the 'option' and (if present) the 'parameters' have to be separated with one or more spaces. You can make any mixture of upper and lower case ! │You can insert comment-lines into your FileDoor.CFG by putting the │%-character on position 1 of the desired line(s). Also empty lines │are considered as comment. It won't take that much longer for FileDoor │to start when there are many comment-lines. The logic of FileDoor will │handle these lines with great speed. Some of the parameters in the FILEDOOR.CFG file can be overruled with command-line switches. A generalized example of FILEDOOR.CFG is included in the release-file. It contains ALL options available in this release. The following sub-chapters of 3.3 will contain the several statements you can use in FILEDOOR.CFG. In the documentation, the statements are put in logical groups. These groups contain statements with the same sort of functions. The actual order of the statements in FILEDOOR.CFG does not matter at all. │3.3.1 Very special statements. │──────────────────────────────────────────────────────────────────────── │The following statement(s) are very special and should only be used in │very special cases. │ │┌─────────────────────────────────────────────────────────────────────┐ ││ Debug [debug-file] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : I have learned from earlier versions that some of the most │ difficult problems is to find a specific error. This is be- │ cause a unknown number of unknown programs (protocols and │ exits) can make use of FileDoor and the basic level of the │ common user can vary from poor to very good. │ │ If you ever have a strange problem and the error does not │ look obvious, you could consider to set this option on. │ [debug-file] must point to a drive, directory and filename │ of a log-file that can grow very huge if used for several │ days. Also FileDoor does NOT share the log, so every File- │ Door (on every single line) must point to a different log. │ │ Inside the log you can find references to names and values │ that will not have much meaning for you, but most important, │ you can also find the Bimodem-alike, DSZ-alike and OPUS-alike │ log-records (that are normally deleted by FileDoor after the │ download). │ │ When reporting an error, I can ask you to send me a part of │ the debug-log, so be prepared when you enter a problem to │ have a debug-log ready or try to recreate the error first │ with the debug-log on. You can always consult me first ! │ │ Setting Debug to on means that there is a little drawback in │ speed (but not in file-search). Also there can be some extra │ disk-access, so the total loss in speed is variable for every │ system. I would not advise to set Debug to on as a default ! │ │Example : Debug C:\SYS\TMP\XFDDEBUG.L01 3.3.2 Basic Parameters ──────────────────────────────────────────────────────────────────────── The following statements are more or less basic statements. ┌─────────────────────────────────────────────────────────────────────┐ │ BBSLine [line] │ └─────────────────────────────────────────────────────────────────────┘ Usage : As said before, in multi-line operations, FileDoor must know the line it is running on. By default, FileDoor uses line 1, so when you run one single line, both -N and/or this option can be omitted. There are some reasons to put the line inside FileDoor.CFG when you run multiple lines: - There is a flaw in Remote Access with the *N option that makes the system of generic menu's for all lines very difficult to use with FileDoor (see chapter on multiline operations); - Your command-line is getting to long; - You can see the which line-number belongs to this CFG file; [line] must be the BBS-linenumber and can be set in the range from 1 to 99. Example : BBSLine 3 ┌─────────────────────────────────────────────────────────────────────┐ │ System [system] [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This defines the BBS system you run and the fileareas. [system] must be RA0 for RemoteAccess versions up to 0.04, RA1 for versions 1.00 or later, QBBS for QuickBBS or SBBS │ for SuperBBS 1.11+. If your SBBS system does NOT support │ the usage of FLSEARCH.BBS, you must install FileDoor as a │ QuickBBS door and make use of the FLSEARCH.CTL file. Details │ for the layout of this file can be obtained from the author │ or from the latest QuickBBS documentation (2.64). [path] must contain the complete path to FILES.RA (RemoteAccess), │ FLSEARCH.CTL (QuickBBS) or FLSEARCH.BBS (SuperBBS). When run- │ ning with QuickBBS 2.75ß, you must still use the old type of │ FLSEARCG.CTL format, but the new format is included in File- │ Door version 2.10 and up. Example : System RA1 D:\BBS\RA\FILES.RA │ System SBBS D:\BBS\SBBS\FLSEARCH.BBS ┌─────────────────────────────────────────────────────────────────────┐ │ NoAutoUpdate [directory] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Some of the supported BBS programs can reload the information from EXITINFO.BBS. At this moment the RA 0.04 and higher and the SBBS (with *E used) can do so and the QuickBBS 2.xx can not (though this will change in the newer releases). If your BBS does not support the reload of information from EXITINFO.BBS (e.g. QuickBBS) OR you dislike the direct up- dates that FileDoor will perform when the BBS is able to do so (RA, SBBS), you can set NoAutoUpdate. In this case FileDoor will create a FileDoor.UPD in the CURRENT directory and will use that file for the user-credits (see chapter on FD_UPD). [directory] must point to the valid directory that will contain FILEDOOR.UPD. All lines (if multi-line) must access the SAME FILEDOOR.UPD otherwise your users can swap lines and download as many as [lines] times the number of files as allowed. WARNING: NoAutoUpdate is NOT needed for RA0, RA1 and SBBS systems, neither will it be needed for the new QuickBBS 2.7x (running beta) but IS needed for QuickBBS 2.6x and lower !!!!!!!!!!!!!!!!!!!!!!!! 3.3.3 Paths ──────────────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────────┐ │ FileDoorDir [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set FileDoor will search for it's menu and help files in the supplied path. If not set, FileDoor will create the menu by its own. Help-files and menu-files must all be put inside │ this directory when used. By DEFAULT they must have the fol- │ lowing names but you CAN overrule them with a name you choose │ yourself (see ANSASC option): MNU_DOWN.ASC/ANS (download menu) MNU_BIDI.ASC/ANS (bidirectional menu) MNU_UP.ASC/ANS (upload menu) HLP_DOWN.ASC/ANS (help on download ) HLP_BIDI.ASC/ANS (help on bidirectional) HLP_UP.ASC/ANS (help on upload ) HLP_SELE.ASC/ANS (help on fileselection) Examples of these files are available inside the release archive. Example : FileDoorDir D:\BBS\RA\TXTFILES ┌─────────────────────────────────────────────────────────────────────┐ │ UploadPath [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will use this directory for uploaded files. This directory is overruled by the -U[path] on the command- line that is used to call filedoor (if available). If this is the case, FileDoor will not check the UploadPath option for valid data; Example : UploadPath D:\BBS\RA\FILES\UPLOADS ┌─────────────────────────────────────────────────────────────────────┐ │ PUploadPath [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will use this directory for uploaded files that are marked private (description starts with /) to the Sysop. If this option (or -P on the call) is NOT available but private uploads are allowed, FileDoor will move these uploads to the normal upload-directory. This directory is overruled by the -P[path] on the command- line that is used to call filedoor (if available). If this is the case, FileDoor will not check the PUploadPath option for valid data; Example : PUploadPath D:\BBS\RA\FILES\PRIVATE │┌─────────────────────────────────────────────────────────────────────┐ ││ DupePath [path] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : If set, FileDoor will move ANY file, marked as a dupe, to │ this directory. Normally FileDoor will delete the dupe file. │ Even if you use this option, FileDoor will NOT count the │ dupe but you can still have a peek at it because it is not │ scratched. │ │Example : DupePath D:\BBS\RA\FILES\DUPES │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ LogFile [path] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Choose the logfile for logging all Filedoor activities. │ The format of the log-file is free and MUST be set with │ the special log-file options (see later on). This allows │ both standard logging (designed to the same format as the │ log that the BBS program makes) and non-standard logging │ (something YOU like). The older 2.xx versions of FileDoor │ needed a parameter to set the type of log ! │ │ Please remember to point to VARIOUS log-files for each line │ you run, unless you want trash in you log or on your disk. │ │Example : LogFile D:\LOG\RALIN01.LOG ┌─────────────────────────────────────────────────────────────────────┐ │ UploadLog [directory] │ │ UploadLog [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Sets a special logfile for all uploads including the name of the uploader. Either use a directory or a fully specified filename including a path. When you use the indirect option (only [directory] set to a directory), FileDoor will create a FDUPLOAD.LOG in that directory. If you use the direct op- tion, you must assign the name yourself. Please remember to point to VARIOUS log-files for each line you run, unless you want trash in you log or on your disk. Example : UploadLog D:\LOG\UPLOAD02.LOG (UPLOAD02.LOG for line 2) UploadLog D:\LOG\ (FDUPLOAD.LOG in \LOG ) ┌─────────────────────────────────────────────────────────────────────┐ │ DownloadLog [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Sets a special logfile for all downloads including the name of the user. Either use a directory or a fully specified filename including a path. When you use the indirect option (only [directory] set to a directory), FileDoor will create a FDDNLOAD.LOG in that directory. If you use the direct op- tion, you must assign the name yourself. Please remember to point to VARIOUS log-files for each line you run, unless you want trash in you log or on your disk. Example : DownloadLog D:\LOG\DNLOAD02.LOG (DNLOAD02.LOG for line 2) DownloadLog D:\LOG\ (FDDNLOAD.LOG in \LOG ) ┌─────────────────────────────────────────────────────────────────────┐ │ SwapPath [directory] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Sets the directory where FileDoor will place any swap-files. Only the directory is allowed. FileDoor will generate any filename by itself, based on the BBS-line and the type of swap. Remember that there must be at least 200K free on the disk you point to for every copy of FileDoor that is swapped (see chapter on swapping). Example : SwapPath E:\ZIP ┌─────────────────────────────────────────────────────────────────────┐ │ TempPath [directory] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Set the path where FileDoor will place uploads and temporary files while work is in progress. FileDoor will put uploads in a temporary directory first. Also some small files, de- pending on the protocol, are placed inside this directory. You can assign a directory on the same drive as where the uploads will be put, because FileDoor will use an intelligent move (move without data transport) when the temporary- and upload directory are on the same drive. FileDoor will always create a directory UNDER this directory to use as the tempo- rary directory and will generate the name by itself (depen- ding on date/time and BBS line). Best thing you can do is to let this option point to the same directory as the up- load directory. FileDoor will remove the directories that are created UNDER this directory; Example : TempPath D:\BBS\RA\FILES\UPLOADS ┌─────────────────────────────────────────────────────────────────────┐ │ BimodemCfg [path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Set the path to the BiModem.Cfg (Bimodem configuration file). You MUST use this option when you include Bimodem in the protocols. It must point to the name and location of the Bimodem.CFG that is used for this (or all) line(s). FileDoor will use this file as a template for a temporary copy of the Bimodem.Cfg. Various things (like com-port) are overruled by FileDoor, so you can use one single (template) Bimodem.CFG. Example : BimodemCfg D:\BBS\PROTOCOL\BIMODEM.CFG ┌─────────────────────────────────────────────────────────────────────┐ │ AlternateFilesPath [directory] │ └─────────────────────────────────────────────────────────────────────┘ Usage : When running with Remote Access 1.xx (or higher), you can have CD-ROM files with separate FILES.xx files. In RACONFIG there is an option that will point to the directory that contains these copies of FILES.xx. Set this option to the same directory. Example : AlternateFilesPath D:\BBS\RA\FILES │3.3.4 Statements that define the logging format │──────────────────────────────────────────────────────────────────────── │In general, FileDoor can write log-records to 3 different log-files │with a fully free format. The three logs are: │ │- System log │ Overhere FileDoor will write records for uploaded and downloaded │ files (e.g. the log-file that the BBS program also maintains); │- User upload-log │ Overhere FileDoor will write records for uploaded files; │- User download-log │ Overhere FileDoor will write records for downloaded files; │ │As told, you can use a free format of the log-records for any of the │three files BUT it is advised to make the records in the system-log │of the same format as the actual records, created by the BBS program. │In this way, log-file analyse programs can include these records as │if they were from the BBS itself. The other two logs can be coded in │a free style UNLESS you use a third-party log-analyse program that │also included these FileDoor-specific log-files. │ │One major and VERY important aspect of the next options is, that if │you do not define them (while having the LogFile, Downloadlog and/or │Uploadlog options active), FileDoor will write EMPTY lines in one or │more of these logs. To be more specific: │ │- When LofFile is set, BBSDNFormat and BBSUPFormat must also be set; │- When DownloadLog is set, UseDNFormat must also be set; │- When UploadLog is set, UseUPFormat must also be set; │- When a ???DNFormat or ???UpFormat (where ??? is BBS or USE) is set, │ you will also have to set ???DateFormat and ???TimeFormat, other- │ wise there is no date/time stamping in the log-file. │ │The following options are available (note that in the supplied file │FILEDOOR.CFG, examples are present for the major BBS types). │ │┌─────────────────────────────────────────────────────────────────────┐ ││ BBSDNFormat [Format] │ ││ BBSUpFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : These two options define the format of the records in the │ BBS-log (e.g. the file you point to, using the LogFile op- │ tion) for Download (BBSDNFormat) and Upload (BBSUPFormat). │ [format] is a line with text and/or macro's supplied by you │ and (when macro's are used) replaced by real text by the │ FileDoor program at run-time. All spaces must be replaced │ with an underscore ('_') character (so [format] is one line │ without any spaces in it). You can use any of the following │ macro's inside your format-line: │ │ %D will be replaced with the date. To use this macro, you │ must also set the BBSDateFormat in your configuration │ file (see later for a description of this option); │ │ %T will be replaced with the time. To use this macro, you │ must also set the BBSTimeFormat in your configuration │ file (see later for a description of this option); │ │ %L will be replaced with the letter of the protocol as you │ have defined in the PROTOCOL option of that protocol; │ │ %N will be replaced with the comment belonging to the pro- │ tocol and as defined in the PROTOCOL option for that │ protocol (eg. 'ZModem the best !'); │ │ %U will be replaced with the name of the user who downloaded │ or uploaded the file; │ │ %P will be replaced with the filename AND path of the file │ that was download or uploaded (for uploads ALWAYS the │ normal upload path); │ │ %F will be replaced with the filename of the file that was │ download or uploaded (no paths); │ │ %X will be replaced with *DUPE* if the file was a dupe at │ upload. │ │ A remark on the %X option. If you do NOT include it in the │ BBSUPFormat statement, no log-records will be created for │ dupes (this is normally the case). If you like a record of │ your dupes, you can either use the %X in the UseUPFormat │ statement or even include it in the BBSUpFormat option, but │ remember that logfile analyse programs can have problems │ with it; │ │Example : BbsDNFormat +_%D_%T_FDOR_Download_[%L]_%P │ │ will result in the following line in the log (don't look │ at the replaced date and time, they are defined by the │ BBSDateFormat and BBSTimeFormat) │ │ 28-Aug-91 21:00 FDOR Download [Z] C:\ZIP\DOAFILE.NOW │ │┌─────────────────────────────────────────────────────────────────────┐ ││ BBSDateFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : In the BBSDNFormat and BBSUpFormat, you can use the %D macro │ that will be replaced with the date. To let this actually │ happen, you must define HOW the date will look like. To de- │ fine this, you must use this option. │ [format] is the format of the date. It will be composed of │ special macro's and some text added by you. The following │ macro's are available: │ │ dd : replaced with the day (leading zeroes); │ DD : replaced with the day (leading spaces); │ mm : replaced with the month (leading zeroes); │ MM : replaced with the month (leading spaces); │ yy : replaced with the year (leading zeroes); │ YY : replaced with the year (leading spaces); │ nnn : replaced with the name of the month (format Jan); │ NNN : replaced with the name of the month (format JAN); │ www : replaced with the name of the day (format Mon); │ WWW : replaced with the name of the day (format MON); │ │ Futher you can use '-' or '/' to separate the different │ digits. In [format] any spaces must be replaced with an │ underscore character. │ │Example : BbsDateFormat dd-nnn-yy will result in 01-Aug-91 │ BbsDateFormat mm/dd/yy will result in 08/01/91 │ BbsDateFormat www dd NNN will result in Tue 20 AUG │ │┌─────────────────────────────────────────────────────────────────────┐ ││ BBSTimeFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : In the BBSDNFormat and BBSUpFormat, you can use the %T macro │ that will be replaced with the time. To let this actually │ happen, you must define HOW the time will look like. To de- │ fine this, you must use this option. │ [format] is the format of the time. It will be composed of │ special macro's and some text added by you. The following │ macro's are available: │ │ hh : replaced with the hour (leading zeroes); │ HH : replaced with the day (leading spaces); │ mm : replaced with the min (leading zeroes); │ MM : replaced with the min (leading spaces); │ ss : replaced with the sec (leading zeroes); │ SS : replaced with the sec (leading spaces); │ t : replaced with the 'a' or 'p' for 'am' and 'pm' │ e : replaced with the 'm' from 'am' or 'pm' │ │ Futher you can use ':' or ' ' to separate the different │ digits. In [format] any spaces must be replaced with an │ underscore character. │ │Example : BbsTimeFormat hh:mm:ss will result in 21:00:01 │ BbsDateFormat HH:mm:ss will result in 1:01:00 │ BbsDateFormat hh:mm te will result in 08:07 am │ │┌─────────────────────────────────────────────────────────────────────┐ ││ UseDNFormat [Format] │ ││ UseUpFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : These two options define the format of the records in the │ log pointed by DownloadLog (UseDNFormat) and UploadLog │ (UseUPFormat). They work the same as the BBSDNFormat and │ BBSUPFormat options ! │ │┌─────────────────────────────────────────────────────────────────────┐ ││ UseDateFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Used for the date format in the UseUPFormat and UseDNFormat │ options. The same as BBSDateFormat. │ │┌─────────────────────────────────────────────────────────────────────┐ ││ BBSTimeFormat [Format] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Used for the time format in the UseUPFormat and UseDNFormat │ options. The same as BBSTimeFormat. 3.3.5 Other statements, not related to protocol definition ──────────────────────────────────────────────────────────────────────── │┌─────────────────────────────────────────────────────────────────────┐ ││ Color [lowmenu] [highmenu] [attention] [statusbar] [errors] │ ││ [text] [size UnC] [Size Com] [date] [time] │ │└─────────────────────────────────────────────────────────────────────┘ Usage : You can overrule the default colors to make FileDoor look │ more the way your own BBS looks. There are 10 items that can be overruled. They are the menu-color (low) [lowmenu], the menu-color (high) [highmenu], the attention-color [attention], the statusbar-color [statusbar], the color │ of the errors [error], the color of text inside the <V> │ and <I> options [text], the color used for sizes (uncom- │ pressed) [Size Unc], the color used for sized (compressed) │ [Size Com], the color of the date [date] and time [time]. │ The last 5 colors are only used inside the <V> and <I> op- │ tions in the download selection menu. Each of these variables must be coded when Color (or Colour) is used. They must contain a number between 0 and 255. The color you want to use is made up with the following formula: [forground-color] + (16 * [background-color]) (normal) or [forground-color] + (16 * [background-color]) + 128 (blink) [Foreground-color] can be a number from 0 to 15, and the [background-color] can be a number from 0 to 7. When you use higher numbers on background-color (8 to 15), you get blinking reversed text (not nice). The numbers 0 to 15 stand for: 0 = Black 8 = DarkGray 1 = Blue 9 = LightBlue 2 = Green 10 = LightGreen 3 = Cyan (sea ) 11 = LightCyan 4 = Red 12 = LightRed 5 = Magenta (purple) 13 = LightMagenta (light purple) 6 = Brown (orange) 14 = Yellow 7 = LightGray 15 = White So to create a cyan on black item, this will come to 3 + (16 * 0) = 3 and for a white on red text this will come to 15 * (16 * 4) = 79. For blinking, add 128 to the number. Example : Color 2 10 14 47 12 6 7 8 4 12 (a 'green-based' FileDoor) │┌─────────────────────────────────────────────────────────────────────┐ ││ HelpExitKeys │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : Normally, FileDoor uses the '?' key for help and the '-' key │ to terminate (both in the protocol selection menue). If you │ would like some other characters (like 'H' and 'Q') you can │ include them in the HelpExitKeys option. ALWAYS define this │ option BEFORE any PROTOCOL option because FileDoor checks │ to see if there are duplicate keys used for different proto- │ cols and/or functions. │ │Example : HelpExitKeys H Q │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ NotAvailText [text] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : On two places FileDoor reports '[FileDoor] no description │ available'. This is while in the file-selection display │ and in the information file, when a file has no description │ inside the Files.BBS (unless HideFiles prevents FileDoor │ from reporting the file at all). │ You can alter this text to any text you like yourself. │ [text] is the new text that is used as a replacement for │ the default text. It can be up to 47 characters and all │ spaces must be replaced with the underscore character. │ │Example : NotAvailText For_this_file_there_is_no_comment │ │ │┌─────────────────────────────────────────────────────────────────────┐ ││ ANSASC [type] [name] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : By default, FileDoor will use the files HLP_DOWN, HLP_UP, │ HLP_BIDI, HLP_SELE, MNU_UP, MNU_DOWN and MNU_BIDI files │ (if present) in the text-directory pointed to by the option │ FileDoorDir (if present). │ │ If you like different help-files and/or menu-files for your │ FileDoor (for example a different setup for line 1 and line │ 2), you can use the ANSASC option to redefine the name of │ the MNU and HLP files. You must still place them in the │ directory that is pointed to by the FileDoorDir option. │ │ The same logic will be used, so FileDoor will first search │ for the [username].ANS and then for the [username].ASC file │ (ANSI-mode) or for [username].ASC in ASCII-mode. │ │ [type] must have one of the following values (there can be │ multiple ANSASC options for several [type]'s: │ │ HU : [name] is searched and not HLP_UP; │ HD : [name] is searched and not HLP_DOWN; │ HB : [name] is searched and not HLP_BIDI; │ HS : [name] is searched and not HLP_SELE; │ MU : [name] is searched and not MNU_UP; │ MD : [name] is searched and not MNU_DOWN; │ MB : [name] is searched and not MNU_BIDI; │ │ [name] is the 1 to 8 bytes name that is used as the replace- │ ment. │ │Example : AnsAsc HU MYHELP_U (look for MYHELP_U.A?? and not HLP.UP.A??) ┌─────────────────────────────────────────────────────────────────────┐ │ AutoSearch │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, a global transfer will be enabled. All file areas will be searched for the wanted file(s). Full security and flag support will prevent users from downloading files from areas they don't have access to. As a guide tp flag-support: - If the sec.level of the area is higher than that of the user, access is denied; - If the sec.level of the area is lower than that of the user, access is allowed; - If the sec.level of the area is equal to that of the user and there are no flags set, access is allowed, else: - If one or more of the flags are not set for the user, access is denied; - If all the same (or more) flags are set for the user, access is allowed; Be sure to understand the security and flag-support with autosearch set because there are many misunderstanding about sec.level and security. FileDoor implements the as above (the same as RA 1.xx). │┌─────────────────────────────────────────────────────────────────────┐ ││ DownloadInfo [file] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : FileDoor contains an option to ask the user if she/he wants │ the comments for the downloaded files copied from your own │ FILES.BBS's to a special file that can be downloaded. The │ user must enter /INFO in the selection option in this case. │ │ If you would like your users to have this option, you must │ create a text-file that contains the header of the file │ that is sended when the user selects /INFO. You can include │ a commercial or some information of interrest. │ │ The temporary file for the user is created in the same │ directory that contains [file] and is deleted when the │ user exits from FileDoor (even when the file was not down- │ loaded at all). │ │ The user will receive a file in the FILES.BBS style and as │ a service, your files-counter (if defined in FileDoor) is │ removed from the comment. The comment can be up to 240 │ bytes in length and FileDoor will be able to support the │ QFV/C/F <tm> +-comment-lines in your FILES.BBS. │ │ [file] must point to a text-file. The parameter must con- │ tain the drive, directory and filename of the file. │ │Example : DownloadInfo D:\BBS\RAX\XFDFBBSI.TXT ┌─────────────────────────────────────────────────────────────────────┐ │ ExactMatch │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will not ask questions when an exact match between mask and filename (e.g. the mask does not contain wildcards) is found. Also searching for other files with this mask is also disabled. Other masks will still be searched for and everything stays the same as before (2.01a) when a user includes wildcards in the mask. See chapter 4.6 for a dis- cussion on file selection. ┌─────────────────────────────────────────────────────────────────────┐ │ QuickMatch │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will not ask questions when a match is found (e.g. the first match) independent of the fact if the user used wildcards in the mask. See chapter 4.6 for a dis- cussion on file selection. ┌─────────────────────────────────────────────────────────────────────┐ │ HideFiles {seclevel} │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, this option will force FileDoor to check if a file inside an area also exists in the FILES.BBS. If this is not the case and the user has a lower security level than the value of {seclevel}, the file is not displayed nor selected. This option works globally over all area's (autosearch) and for all files that are not in FILES.BBS. {seclevel} can be included to make special users still use the option to select files that are not inside FILES.BBS. By default {seclevel} is 0, so when the option is included without {seclevel} NO user can select the files that are not inside FILES.BBS; ┌─────────────────────────────────────────────────────────────────────┐ │ FilesCount {format} │ └─────────────────────────────────────────────────────────────────────┘ Usage : If used, then, after a download, all FILES.BBS files will have their filecounters updates. This way you will be able to track the number of downloads of each file in your library. {format} indicates the number of digits used in your files- counter AND the characters that incapsulate the counter. You can use @ or # for the counter, where @ will cause tailing zeroes and # will cause tailing spaces and any combination of incapsulation characters. If {format} is left out, [@@] is the used default. FileDoor uses a smart update. Downloads of multiple files are collected and FILES.BBS is opened only once. Example : FilesCount [@@@] (will cause [001] xxxxx) FilesCount [##] (will cause [ 1] xxxxx ) FilesCount {@@} (will cause {01} xxxxx ) ┌─────────────────────────────────────────────────────────────────────┐ │ CommentLength [option1] [option2] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This will define the minimum and maximum length of the filedescriptions for uploaded files. You must supply the real minimum and maximum length including the files-counter. Defaults are 20 and 47. You can define a length up to 240 characters. Example : CommentLength 20 47 ┌─────────────────────────────────────────────────────────────────────┐ │ FreeFile [filename] │ │ FreeFile [drive:path\mask] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will not calculate the kB's downloaded for the supplied file names. Either use [filename] with a full filename as global name for ALL areas or [drive:\path\mask] for files in specific areas. The second option allows the usage of wildcards. Example : FreeFile D:\BBS\RAX\FILE\DISP\MT*.* FreeFile MLP*.* ┌─────────────────────────────────────────────────────────────────────┐ │ DefaultExtension [extension] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Set the default extension for wilcards or partial filenames. This will also be displayed in the file selection part of FileDoor. If no extensions are used in your filebase remember to set [extension] to '*'. When set to ZIP (for example), a filename MYBBS* will be expanded to MYBBS*.ZIP and FileDoor will search for that file. If the user enters any extension or wildcard as extension, none is added by FileDoor. Example : DefaultExtension ZIP ┌─────────────────────────────────────────────────────────────────────┐ │ Unwanted [filename] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Set any filename or extension that is unwanted for an upload on your system. Both filenames and wildcards may be used. Example : Unwanted *.GIF Unwanted PKZ110.* Unwanted ARJ200.EXE ┌─────────────────────────────────────────────────────────────────────┐ │ NoArchiveCredit [amount] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Set the credit for non-archived files. FileDoor will test the uploaded file for any known compression method. The calculation is as follows: (filesize / 100) * NoArchiveCredit. You do not have to tell FileDoor the extensions or archives, because FileDoor will look inside any uploaded file by itself and will detect ARC, PAK, PKA, ZOO, ZIP, ARJ, LU, DWC, MD, HYPER, LHA, LHarc and LArc files by itself (normal and SFX files). Example : NoArchiveCredit 50 ┌─────────────────────────────────────────────────────────────────────┐ │ AlienArchive [extension] │ └─────────────────────────────────────────────────────────────────────┘ Usage : FileDoor has a build-in knowledge of most normal archivers. Some other files could also be archives but of the type that FileDoor does not know internally. GIF/BMP/TIF/PCX and such could be such files. You can add up to 10 AlienArchive options. [Extension] is the extension of these special files. FileDoor will first look if the file is a normal archive and then take a look at the AlienArchive options to see if you have included this file. Please add at least 'AlienArchive GIF' (if you want the to be counted as archives) because 2.01a contained coding to see a GIF as an archive but 2.02 does not contain this coding anymore. Example : AlienExtension PCX ┌─────────────────────────────────────────────────────────────────────┐ │ Ratio [sec] [ratio] [K|F] [threshold] │ └─────────────────────────────────────────────────────────────────────┘ Usage : You can have FileDoor check the current users file ratios and allow him depending on these figures to download or not to let him download files from your system. Both KiloBytes and number of files are allowed. The first option is the user's security level, the second the ration he must maintain, the third one decides wether the amount of kB's or the number of downloaded files is tested. The fourth option is the free threshold for ratios. FileDoor will allow downloads until the number set in the fourth parameter. Only when this number is reached, Filedoor will start counting the downloads, with the files downloaded during the free threshold counted in. Up to 100 ratios are allowed, but only one per security level. Example : Ratio 100 10 F 20 (level 100 must maintain a 1:10 filenumber ratio, but until the 20th file the download is not counted in the ratio). Ratio 5 8 F (level 5 must maintain a ratio of 1:8 for number of files and there is no threshold). Ratio 99 10 K 200 (level 99 must maintain a ratio of 1:10 for the number of transferred kB's, but no ratio is check until he has reached 200Kb of downloads). ┌─────────────────────────────────────────────────────────────────────┐ │ PrivateUploads │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set the private uploads (to the Sysop) are allowed. The description is placed in a separate file, PFILES.BBS in the upload directory. The user has to start the filedescription with a '/' to make an upload private. ┌─────────────────────────────────────────────────────────────────────┐ │ TouchUploads │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set all uploads will get the date/time stamp of your system and not the original date/time. This way all uploads will be displayed as *NEW* files. ┌─────────────────────────────────────────────────────────────────────┐ │ ULMultiply [sec] [%count] │ └─────────────────────────────────────────────────────────────────────┘ Usage : For any upload done by user with security [sec] the number of KB's will be multiplied with the percentage in [%count]. [%count] may even be smaller than 100%, but what is the use for such a function. Will save much disk-space on you upload disk though. Non archived files will first be reduced with the percentage in NoArchiveCredit and then be multiplied by the percentage of ULMultiply. Version 2.05 and higher will also contain a credit in time. This is dropped for the moment because it is very difficult to access these figures for all supported BBS's at this mo- ment (unless type 15 is used). Example : ULMultiply 100 200 (all uploads for level 100 will give a 200% credit in KB's). ┌─────────────────────────────────────────────────────────────────────┐ │ AskAnother │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will ask the user if he wants to perform another file-transfer after completing a transfer. ┌─────────────────────────────────────────────────────────────────────┐ │ TimeOut [amount] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This will set the number seconds before FileDoor will timeout a user for inactivity. This way you will prevent a user to enter FileDoor and use all his BBS access time doing nothing. After timing out a user he will be warned and eventually be returned to the BBS. Example : TimeOut 120 ┌─────────────────────────────────────────────────────────────────────┐ │ NoLastChance │ └─────────────────────────────────────────────────────────────────────┘ Usage : If the user choses to disconnect immediately after a transfer FileDoor will ask the user to press any key to terminate the hang-up process. NoLastChance will disable this feature. ┌─────────────────────────────────────────────────────────────────────┐ │ MinSpace [amount] │ └─────────────────────────────────────────────────────────────────────┘ Usage : With this option you will be able to set the minimum of disk-space that must be free for allowing uploads to your system. [amount] is set in kB's. Bidirectional transfers will only display the minimum space but will allow uploads anyhow. If the option is left out, no compare is made but the availa- ble space will be displayed only. Example : MinSpace 1000 ┌─────────────────────────────────────────────────────────────────────┐ │ NoEMS │ └─────────────────────────────────────────────────────────────────────┘ Usage : When this option is available, FileDoor is forced to ignore EMS for swapping space (if needed). If there is still XMS or Extended Memory, FileDoor will use this type of memory. If neither of these two resources is available, FileDoor is forced to use disk-space. When NoXMS is also present in the FileDoor.CFG, disk-space is always used for swapping; ┌─────────────────────────────────────────────────────────────────────┐ │ NoXMS │ └─────────────────────────────────────────────────────────────────────┘ Usage : When this option is available, FileDoor is forced to ignore XMS and Extended Memory for swapping space (if needed). If there is still EMS, FileDoor will use this type of memory. If EMS is not available, FileDoor is forced to use disk- space. When NoEMS is also present in the FileDoor.CFG, disk- space is always used for swapping; ┌─────────────────────────────────────────────────────────────────────┐ │ DownloadHours [start] [stop] │ └─────────────────────────────────────────────────────────────────────┘ Usage : With this option you can set the type that your system allows downloads. You can set as many download hours as needed, as long as they don't pass the 23:59 border. Both [start] and [stop] use the 24 hour time format. FileDoor will combine all available DownloadHours options into a up/down table. Example : DownloadHours 0900-1200 DownloadHours 1500-2200 ┌─────────────────────────────────────────────────────────────────────┐ │ CheckDupes │ └─────────────────────────────────────────────────────────────────────┘ Usage : If set, FileDoor will perform a dupe-check (internally) on the uploaded files. All dupes are removed before they are counted. TRY.ZIP is considered a dupe with TRY.ARC but TRY.ARJ is NOT considered a dupe with TRY.ALL. Archive extensions that will be tested are ARC, PAK, PKA, LZH, LZS, ZIP, ZOO, DWC, MD, HYP, ARJ, SDN. If this check is to raw for your taste, you can insert an exit (hook) in one of the ExitAfterUpload options. The called file will then be responsible to remove (and report) the duplicated files. ┌─────────────────────────────────────────────────────────────────────┐ │ TagFileMacro [directory] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This version of FileDoor allows third party utilities to supply a tag file to FileDoor. This way programmers have a way to pass on a list of selected files to FileDoor. FileDoor will detect the tag files from RFW (c) and MTS (c) automatically. The struc- ture of this FileDoor/DISP-compatible tag-file is present in the release-archive. [directory] must point to the common location where the tag- files are placed. MTS and RFW have installation options to point to that directory. The filename is composed by FileDoor itself. Please read the chapter on tagging for more details on the FileDoor/DISP-compatible tag-file. Example : TagFileMacro D:\BBS\RA ┌─────────────────────────────────────────────────────────────────────┐ │ NewFileMacro [seclevel] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If this option is enabled FileDoor will allow your users with a security level of [seclevel] (and higher) to easily detect, select and download NEW files since their last logon to your system. Example : NewFileMacro 100 ┌─────────────────────────────────────────────────────────────────────┐ │ UserMacro [tag] [auto] [desc] [mask] {sec} │ └─────────────────────────────────────────────────────────────────────┘ Usage : This option allows a user with security {sec} to use /[tag] in the fileselection menu. Filedoor will replace the [tag] with [mask] in the search procedure. [desc] is the description of the macro. [tag] can be any combination of characters with a maximum of three. [desc] may be up to 30 bytes long. Words in the description [desc] must be separated with the underscore ('_') character. [auto] must be either 'Y' or 'N'. If 'Y' is selected, File- Door will display this macro (tag) at startup and in the help-screen. If 'N' is set, the user must use /? to display all available tags (macros). And the tag (macro) is not displayed at startup. There can be up to 100 tags (magical names is a better description) but there is no check on duplicates, neither on the usage of NEW for [tag]. NEW is reserved as is TAG, because they are used (/NEW, /TAG) for selecting new-files and tag-files. Example : UserMacro MTA N The_newest_MTA_Package MTA_V???.??? 20 UserMacro ALL N All_files_on_the_BBS ALLFILE*.??? ┌─────────────────────────────────────────────────────────────────────┐ │ SysopPassword [password] [sec] │ └─────────────────────────────────────────────────────────────────────┘ Usage : If a users enters // in the fileselection menu she/he will be presented with the new questions: 'Enter password' and 'Give full path and filename of the the wanted file'. This way the cosysop or every other user user you give knowledge of the password and has the right security, will be able to download from every directory on your system if hers/his sec.level is the same or higher than [sec]. [password] can be up to 20 characters without spaces. The case is not important. The user must enter a filename (full) and (optional, when the file is not in the current directory) a full path to the file (including drive when the directory is not on the current drive). Only one file at the time can be selected (no wild- cards allowed) but // can be used multiple times before the actual download has to start. WARNING: There is no other check whatsoever to the selected file and your complete system is open for download. Example: SysopPassword MySecretPwd ┌─────────────────────────────────────────────────────────────────────┐ │ ExitAfterSelect Drive:\Path\Filename.Ext [options] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This exit is called after EVERY 'Y' on a file-select with download. If the called program returns errorlevel 0, the file is allowed, if the errorlevel is 1 or higher, the selection is denied even after FileDoor has allowed it before. [options] must be the command-line for the specified program. You can include multiple macros (described later) to be replaced by FileDoor. Example : ExitAfterSelect C:\UTILS\CALCUSER.EXE $C $B $U │┌─────────────────────────────────────────────────────────────────────┐ ││ ExitAfterDownload Drive:\Path\Filename.Ext [options] │ │└─────────────────────────────────────────────────────────────────────┘ │Usage : This exit is called after the download (succesfull or not) │ and for EVERY file that was selected. │ In combination with the ExitAfterSelect you can deside to │ do something to the selected files (for example, add a file │ or comment with your compress-program) in the ExitAfterSelect │ and reverse this action on the ExitAfterDownload option to │ reset the file to its original state. The problem of file- │ sharing is up to the program that is called in the exit. │ │ In a later version, special options will be available to │ add files and/or comments to archives before the trans- │ mission and remove them afterwards but until then this could │ be something for you ! │ │ [options] must be the command-line for the specified program. │ You can include multiple macros (described later) to be re- │ replaced by FileDoor. │ │Example : ExitAfterDownload C:\UTILS\CALCUSER.EXE $C $B $U ┌─────────────────────────────────────────────────────────────────────┐ │ ExitAfterUpload1 Drive:\Path\Filename.Ext [options] │ │ ExitAfterUpload2 Drive:\Path\Filename.Ext [options] │ │ ExitAfterUpload3 Drive:\Path\Filename.Ext [options] │ └─────────────────────────────────────────────────────────────────────┘ Usage : These exits are called after the upload. You can implement 3 of them. The exits are on their own. The fossil is closed by FileDoor and parameters are passed to the called program. [options] are the same as with the previous ExitAfterSelect options. The command-line parameters for the called program can also include macros that are replaced by FileDoor. The following macros are available to be implemented into the command-line [options] of the called program: - $C will be replaced with the Com-port number - $B ,, ,, ,, ,, ,, Baud-rate - $T ,, ,, ,, ,, ,, time-left to the user - $S ,, ,, ,, ,, ,, allowed download-limit - $Z ,, ,, ,, ,, ,, DSZLOG env. variable - $U ,, ,, ,, ,, ,, upload-path - $F ,, ,, ,, ,, ,, filename (ExitAfterSelect) - $D ,, ,, ,, ,, ,, path to EXITINFO/DORINFO1 - $M ,, ,, ,, ,, ,, swap before exit is called A special note on the ExitAfterUploadx exits. A called pro- gram can copy a file with the same name but with extension F$D into the upload-directory. When this is the case, a special routine will be triggered. FileDoor will obtain the size of the original file from this file and will NOT take the actual size. This routine is created so that recompres- sion (not recommended !!) can be done inside one of the exits while FileDoor can still credit the user for the actual number of bytes that were uploaded. One recompression program that can do this job is MTA (version 14.45) with it's /STOSIZ option. Example : ExitAfterUpload1 C:\UTILS\ZIPZOOM.EXE $C $B $U 3.3.6 Filedoor's Protocol Definition ──────────────────────────────────────────────────────────────────────── This will be the toughest part of the Filedoor.Cfg. In this part you will be shown how to install external protocols in FileDoor. An example with almost every known external protocol has been included in the package. We strongly urge all filedoor users to share their knowledge and experience with other and new protocols in FileDoor with the author. This way we are able to update the examples and help users installing these protocols in FileDoor. Please sent your information to the author by Net or SnailMail or use the international echomail area DISP. Every protocol statement in FileDoor.Cfg consists of 2 lines. The first line start with the keyword 'protocol' and is followed by a number of parameters. The general format of this line is as follows: ┌─────────────────────────────────────────────────────────────────────┐ │ Protocol [effic] [letter] [way] [max] [MinBaud] [Text] │ └─────────────────────────────────────────────────────────────────────┘ This is the first line that will make up a complete protocol descrip- tion. [effic] Is the efficiency rate of a protocol. This rate reflects the efficiency for this protocol. For those not familiar with this definition I will explain this. Depending on the protocol that is being used, larger or lesser parts of the transferred information is used for flow control and error correction. If this was not being done you might end up with a corrupted file after file transfer. Most protocols will have an efficiency rate of app 95%. IMPORTANT: For the protocol type 'other' you should use a correct value for [effic]. If not correct, FileDoor will assume that the file-transfer has been aborted and will NOT count the transfer. It will be better to set the value too high than too low. [letter] This is the character the user has to enter for selecting this proto- col. You can use almost any letter and special character. You can not define duplicate letters in one [way] (e.g. D, U or B). But you can define duplicate letters in different [way] definitions, so a 'B' for 'D'(ownload), a 'B' for 'U'(pload) and a 'B' for 'B'(idirectional). The characters '-' and '?' are reserved for termination and HELP and can not be used. [way] This is a single letter and is used to let FileDoor know if this is an upload, a download or bidirectional protocol. (U tells FileDoor it is an upload protocol, D tells FileDoor that it is a download protocol and B tells FileDoor that we have to do with a bidirectional protocol. The one and only bidirectional protocol that is supported (bimodem) can be present in 'D', 'U' and 'B'. [max] Is the number of files that can (may) be transferred in one session for this protocol. IMPORTANT: - For non-batch protocols like XModem you must specify '1' for [max] and the user must supply the filename and the filedescription before starting an upload. - FileDoor's built-in maximum for [max] is 255. You must make it sure that the protocol can support that much files in one time. Also, the more specified for [max], the more memory FileDoor will use. - For batch protocols that must have all filenames supplied on the command-line (i.e CLink), you must limit [max] to +- 4 to prevent a command-line overflow error. FileDoor will truncate the command- line to the maximum and report that truncation (that is different from earlier versions that reported an error) and start the protocol for this number. [minbaud] This is the minimum baudrate that is needed for selecting this proto- col. This way you may prevent users to use high-speed transfer proto- cols on a too low baudrate. If you define 0, all users can use the protocol. [text] This is the name of the protocol and is also the text that is shown to a user when selecting a protocol. (FileDoorDir option disabled). This free format text may be up to 30 characters long. ┌─────────────────────────────────────────────────────────────────────┐ │ [subtype] [filename.ext] [options] │ └─────────────────────────────────────────────────────────────────────┘ This is the second line that will make up a complete protocol descrip- tion. The second line of the protocol statement, the subtype of the protocol, will be defined and all info that will be passed to the protocol program. The general format of this line is as follows: [subtype] The following values may be used. They will be explained in detail: DSZ This protocol subtype uses the DSZ.LOG file. So it will work with all transfer protocol that produce a DSZ.LOG compatible logfile. We have tested this subtype with the DSZ transfer program from Omen Tech (tm) version february 1991 and later and with SZModem v1.41 (see examples). OPUS This protocol follows the OPUS v1.0 conventions for external file-transfer protocols. This has been tested with MegaLink, Okermit and CLink. This is a fixed format that will be automatically set up by FileDoor ERRORLEVEL This subtype check if the transfer protocol passes errorlevel '0' to FileDoor after sending a file. If FileDoor detects this errorlevel it assumes that all files are send. OTHER This indicates a protocol driver which does not create any sensible log file amd which does not exit with an errorlevel after sending the file(s). FileDoor simply calculates the transfer time of the files based on size, baudrate and the supplied efficiency rate for this protocol and measures the time that filedoor was running for transferring these file(s). If the files were transfered faster than FileDoor calculated, then no files will be marked as transferred. Using this subtype you must be extremely careful setting the efficiency rate. It is better to set this value too high than too low. It is advised to use another subtype if possible. BIMODEM This indicates the BIMODEM.COM <tm> protocol. It can be used in 'U', 'D' and 'B' types of protocols. 'B' (along with -db) is implemented for those systems that have setup a separate menu for the Bimodem protocol. [filename.ext] This must be either the name of the program (DSZ.COM, BIMODEM.COM and so on) when the protocol can be found on the DOS-path or the full path and name (drive:\path\filename.ext) of the protocol when the protocol is not on the DOS-path. The latter is faster than the first because FileDoor does not start a party-search for all the protocols. For slow disks (machines) the full format is preferred. [options] Here you place the command-line parameters for the specific protocol. You can include some generic macros that are replaced by FileDoor at runtime. These are: - $1 Port number (1=COM1:, 2=COM2: etc) - $2 Baudrate - $3 Response file (for DSZ versions later then 880423) - $4 List of files to be received or sent - $5 Number of minutes left - $6 Number of kB left - $7 Contents of DSZLOG environment variable - $8 Upload Path - $M Swap FileDoor to EMS or disk before executing the protocol An example: keyword Download | efficiency rate | maximum files | | key to start | minimum baud Description | | | | | | | Protocol 92 G D 9 0 YModemG (DSZ) DSZ DSZ.COM Port $1 pB4096 restrict rb -k -g -$3 $M | | \-----------------------------------/ | | | command-line options ($3 = response file) | | Driver | Subtype Swap FileDoor to EMS/disk Some general notes about the command-line: o Calling the transferprogram with a complete path will load the program faster than using the DOS path; o The command-line in FileDoor.Cfg is not limited in length, however the expanded command-line as passed to DOS for execution may not exceed 132 characters. This is DOS limitation; o If you need a batch-file to start your protocol, you may do it as follows: Other C:\COMMAND.COM /C MYBATCH.BAT [options] Study the examples in the supplied FileDoor.CFG careful. There are many users of FileDoor. These users can also help you with you quest for the right options. 3.4 FD_UPD and FILEDOOR.UPD ──────────────────────────────────────────────────────────────────────── For QuickBBS it is (at this moment) impossible to reload information from the EXITINFO.BBS. FileDoor will update EXITINFO.BBS with the new credits (for RA, SBBS) so the BBS can reload this information at once but for QuickBBS this is not possible. In this case (QuickBBS) you must not only set SYSTEM QBBS but also NoAutoUpdate in FileDoor.CFG. This means that FileDoor will start creating a file called FILEDOOR.UPD in the supplied directory. FILEDOOR.UPD is SHARE'ed like FILES.BBS. This can mean a little delay at startup and termination BUT multiple FileDoor copies can access FILEDOOR.UPD at the same time, so you CAN run multi-line without the problems you had in previous versions. When FileDOOR.UPD is created it will grow and grow. Every time FileDoor will start it has to read FILEDOOR.UPD to update the users credits from the USERS.BBS with the figures from FILEDOOR.UPD. For this reason it is needed to empty this file once in a while (at least every 24 hours). In the package you will find a program FD_UPD.EXE. In your event you must run FD_UPD with the FILEDOOR.UPD and the USERS.BBS (QBBS, SBBS or RA) in the same directory. FD_UPD will update the figures from FILEDOOR.UPD to USERS.BBS and at the end, FILEDOOR.UPD is deleted. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 4 │ Runtime information │ └───────┴─────────────────────────────────────────────────────────────┘ 4.1 Command-line switches ──────────────────────────────────────────────────────────────────────── ┌─────────────────────────────────────────────────────────────────────┐ │ -D[option] │ └─────────────────────────────────────────────────────────────────────┘ Usage : Use this command-line option to instruct FileDoor to start a download, Upload or Bidirectional transfer: -DD for Download -DU for Upload -DB for Bidirectional Protocols with [way] 'D' or 'U' (e.g. non-bidirectional pro- tocols) can NOT be included in the set for 'B' (e.g. -DB) but 'B' types of protocols (only Bimodem) CAN be implemented in the 'D' (-DD) and 'U' (-DU) types of protocols. ┌─────────────────────────────────────────────────────────────────────┐ │ -A[path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This tells FileDoor which path to use for downloads. Only needed when AutoSearch is not set. ┌─────────────────────────────────────────────────────────────────────┐ │ -N[digit] │ └─────────────────────────────────────────────────────────────────────┘ Usage : For Multiline setup it is necessary to tell FileDoor which node is calling FileDoor. In RemoteAccess like environments one might call FileDoor like FileDoor -N*N. This option can also be re- placed with the BBSLine option in FileDoor.CFG ┌─────────────────────────────────────────────────────────────────────┐ │ -U[path] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This tells FileDoor which path to use for uploads. This can also be replaced with the UploadPath option in FileDoor.CFG. ┌─────────────────────────────────────────────────────────────────────┐ │ -C[cfg] │ └─────────────────────────────────────────────────────────────────────┘ Usage : This allows you to use another file for FILEDOOR.CFG. [cfg] points to the alternate FileDoor.Cfg. This option allows you to use different setups for each line in a multiline setup. 4.2 Fast Modems ──────────────────────────────────────────────────────────────────────── If you use a modem running with a locked baudrate (HST/Telebit/V32 modems) you need to edit the command-line in the configuration file. Two things need to be changed: 1. Replace all '$2' with the locked baudrate, 1.e. '19200' if you have fixed the baudrate of your modem to 19200 baud. 2. Use the command-line options of the transfer program so that it uses hardware handshake (CTS/RTS). Transfer protocols that use the fossil-driver for all I/O don't need any changes because the fossil driver will take care of the handshaking and the locked baudrate. 4.3 Multiline operations ──────────────────────────────────────────────────────────────────────── FileDoor will work fine in a multiline setup. Previous versions could trash files because there was a chance that the same file was updates at the same time on different lines (FILES.BBS with FilesCount option). This version implements full sharing (when SHARE.EXE is loaded) for those files that can be accessed from different lines at the same time. Excluded are the log-files. You can let FileDoor write to the BBS-log but there must be separate log-files for each line. In some special cases, the user is asked to wait a few moments when FileDoor is busy with updating FILES.BBS on two separate lines at the same time. You should (must) use different FILEDOOR.CFG files for each line you run. A nice way to implement this, is to use the BBS's macro that is replaced with the line-number, inside the call to FileDoor. You should setup a menu type 7 (or 15) in the following way: C:\UTILS\FILEDOOR.EXE -DD -CC:\UTILS\FILEDOOR.CF*N -N*N *M (RA) In this way, a call on line 1 or 2 is expanded into: C:\UTILS\FILEDOOR.EXE -DD -CC:\UTILS\FILEDOOR.CF1 -N1 *M (RA line 1) C:\UTILS\FILEDOOR.EXE -DD -CC:\UTILS\FILEDOOR.CF2 -N2 *M (RA line 1) There is a little flaw in Remote Access that makes it impossible to use the *N more than once on the command-line. You can trick RA and FileDoor by using *P for the first *N in the above command-line but you can only do this when you your port (COM-port) and line are always the same (so line 1 is COM1, line 2 is COM2 and so on). If this is not the case, you can remove the -N*N option and add BBSLine 1 to FILEDOOR.CF1 and BBSLine 2 to FILEDOOR.CF2. All temporary directories and files are made line-specific. FileDoor will use the line-number in all its temporary directories, swapfiles, configuration-files and so on. There are no chances in cross-linking any file. WARNING: FileDoor uses the DSZLOG environment variable. You must set this variable to a directory AND filename for EACH line and the values MUST be different, so, for example, use: SET DSZLOG=D:\BBS\RA\RA1\DSZ.LOG (on line 1) SET DSZLOG=D:\BBS\RA\RA2\DSZ.LOG (on line 2) If DSZLOG is not set, FileDoor will abort and there can be problems when DSZLOG will point to a directory (and not a file) or to an invalid directory. I do not alter the DSZLOG variable to keep FileDoor compa- tible in DOS-boxes, special DOS-versions (ATT 6300 clones to name one) and such ! 4.4 Swapping ──────────────────────────────────────────────────────────────────────── When you run a BBS, you already know what swapping is. FileDoor can swap itself from memory when the protocol is called. In this case you must include $M into the command-line of the protocol(s). FileDoor will first look for EMS, if not available than XMS is used, if not available than extended memory is used, if not available than DISK is used (the SwapPath option !). 4.5 FileDoor/DISP-compatible tag-file <tm> ──────────────────────────────────────────────────────────────────────── FileDoor can use a FileDoor/DISP-compatible tag-file <tm>. This is a special structure, created by other doors like the DISP-programs MTS and RFW. This tag-file will contain all the information for FileDoor to access the filenames contained in this tag-file easy. Other products can give an option to store information inside the tag-file (filenames) and FileDoor can (later) access this informa- tion. In some way, the tag-file is a type of Clipboard where the user stores filenames to remember and that can be recalled by the FileDoor program. FileDoor can use two kinds of tag-files. The first one is a normal tag-file. The user MUST enter /TAG on the FileDoor selection question. The second one is a so called AUTOLOAD tag-file. When the user selects the download-menu, FileDoor will load the tag-file without having to enter the /TAG on the selection line. The user is still able to select or deny the tagged files. MTS and RFW will create autoload tagfiles. When FileDoor recognizes a AUTOLOAD tag-file, it will display all stored files for the user, so the user can add them to the download list or skip them. Also FileDoor will remove the AUTOLOAD flag so the next time FileDoor is started, there is still a tag-file (the same when no new tag-file is created) but the user MUST access the file with /TAG. When FileDoor starts, it will look for BBSTAGFL.n (where n is the line-number). If available, FileDoor will check if this tag-file belongs to this user (with a name-compare). If this is not the case or when the file is not compatible (IO-error, invalid), FileDoor will remove it and /TAG is not possible. 4.6 File selection ──────────────────────────────────────────────────────────────────────── Reading this chapter can make the difference in FileDoor's speed between a turtle and a road-runner (miep-miep). You must think carefully how you will implement file selection for the user. FileDoor offers a complete set of file selection methods but it would be nice if you used the one that suits your environment (and type of users). FileDoor does everything from the point of the 'complete' set. See it as a type of OOP way of working. The 'root' is the complete selection and both you and the users can vary the behaviour of this 'root'. Be warned though that you alter the description of the file selection help-file to the choice you have made. A generalized example of this help-file is included in the release archive. The 'root' is the base of all file selections that the user can make. By default, FileDoor will use this 'root' method. A short description: - The user is presented a line where she/he can enter 1 to the length of he line filemasks. The different masks must be separated with at least 1 space; - After entering, FileDoor starts searching the area(s) for every mask; - When a match is found, FileDoor will ask the user (Y/N) if this is the file that is requested. If 'Y', FileDoor will add it to the list; - In both cases, FileDoor will continue the search in same (and following when AutoSearch is set) area to search for this mask until no match is left in either this or any other area; The big benifit of this way of selecting files is, that it is very friendly for the user, but advanced users will not like it at all. Now there is an escape for this way of working and one that comes close to the way that FileDoor 1.xx used. The user can enter /Q as the last filemask and in this case ALL matches are taken without questions, either until limits are exceeded or there are too many files. The user will jump directly to the protocol (or the question to start the protocol) and can go on from here. Until now the user had only something to tell. The above method has still one problem. When FileDoor finds a match it will still search all eligable area's for more matches for the same file. This is needed in those cases where name-like files can be available in two or more different area's. In that case FileDoor MUST search because the user could want the second (3th and so on) and not the first match. When this is not the case, FileDoor can be implemented with another method. There are two (related, but different) ways to do so: - Add the ExactMatch in FileDoor.CFG; - Now searching will as before but if the user enters a FULL filename (without wildcards), FileDoor will take the first file with that name that is found and no questions are asked for that file; - The user can still make multiple selections by including a wildcard in the name. Now FileDoor will go on searching for this file until all available matches in all areas are processed; There is a more radical method: - Add the QuickMatch option in FileDoor.CFG; - Now searching will be different. If a file matches a supplied mask, the file is taken (no questions) and the mask is removed. Only other masks that did not match until now, will processed until either all files are found (e.g. all masks are removed) or all files are processed (all areas have been processed when autosearch is on); - The user is STILL able to overrule this method but in that case the user must enter /S at the end of list of masks. In that case the search will be the same as with the 'root' method; There is one big advantage with ExactMatch or QuickMatch (never use them both, QuickMatch will overrule ExactMatch but the program can slowdown a bit). This advantage is speed. In the 'root' model, FileDoor keeps on searching, even if all files are already selected, for a pos- sible other match. This is less with the ExactMatch method (but the user must enter full names) and gone with the QuickMatch. The number of informative lines with each option will be less than than with the 'root' method. I suggest you only use QuickMatch on slow machines, big BBS's or those BBS's that have their CD-rom as the last area(s) of the list. The ExactMatch is somewhat inbetween. FileDoor is at its most friendly with both options set to off while there is still a quick method for users who want is. ┌───────┬─────────────────────────────────────────────────────────────┐ │ 5 │ Version information and credits │ └───────┴─────────────────────────────────────────────────────────────┘ 5.1 The BETA-team ──────────────────────────────────────────────────────────────────────── The following Sysop's and their CoSysop's (only if they use the same BBS or a NON-user (closed) shadow BBS) are allowed to make use of the BETA-releases on their own risk: - Remote Access Multiline/Multiport Paradise 2:512/100 (*) Sysop: Reinier De Groot - GOLEM Service BBS 2:242/4 Sysop: Hanstheo Wolf - Sirex BBS 2:280/216 Sysop: Gerry Ulrich - Funboard BBS 2:244/12 Sysop: Dirk Astrath - Nilpferd BBS 2:244/8500 Sysop: Joerg Dassler - The Black Universe 2:403/139 Sysop: Saar Blitz - Hitch Hiker BBS 2:405/166 Sysop: Alon Gingold - Amber Shadow Sysop: Dave Overton 1:203/988 - The Chess Board 1:124/2213 Sysop: Ken Givens - Secret Blue Valley 2:200/407 Sysop: Andreas Birgerson - Barnabas the Caring UK 2:257/168 Sysop: John Barton Thanks to ALL of you for the support, access, reports, suggestions, the nights without sleep, the sleep without nights but foremost the believe that FileDoor would make it again. 5.2 Credits ──────────────────────────────────────────────────────────────────────── Thanks to the following people: - Stig Jacobsen for developing FileDoor and making it possible to create a State of the Art fileprotocol interface. - All registered users. You make it worthwhile to enhance FileDoor with nice features; - All users who did write a message and/or sent me a postcard; - The BETA-team; - Dave and Ken for their long-distance support (a new version of Windows is cheaper and nicer); 5.3 Version history ──────────────────────────────────────────────────────────────────────── ┌───────┬────────────────────────────┐ │ 2.01 │ Complete rewrite │ └───────┴────────────────────────────┘ ■ The first release after the all rights and source codes have been transferred from Stig Jacobsen to Rob van Hoeven. Can still contain bugs (even DOS does) so...... ┌───────┬────────────────────────────┐ │ 2.01a │ Bug release │ └───────┴────────────────────────────┘ ■ Bimodem would fail (displaying help-screen) in some situations. This is fixed; ■ All protocols would give various errors in local mode because most of the time the COM0 (invalid port) was passed. Local testing will now bring a window on-screen with the call that FileDoor will make (program, location, options) when running remote; ■ GIF files were not counted as archives. This is (temporary) fixed by including them as archive extension; ■ Backspace on remote side was not (always) destructive. This is replaced with a 'backspace, space, backspace' combination; ■ Fixed some internal coding. Credit scoring for Bimodem upload in download-menu was not counted. Fixed; ■ PFILES.BBS was a selectable file. This is now fixed. PFILES.BBS and PFILES.BAK are now skipped; ■ Fixed problem with the upload-exits. They were not called when Bimodem (possible uploads!) was selected in -DD or -DB menus; ■ Added a new option, HideFiles; ■ Added support for MTA 14.45 recompressing utility under FileDoor ExitAfterUploadx options; ┌───────┬────────────────────────────┐ │ 2.02 │ 'Minor' and bug release │ └───────┴────────────────────────────┘ ■ Fixed a problem where the download of Bimodem files was not counted at all; ■ Aborted downloads in either DSZ, Other or OPUS flavour were always counted. This could cause the following scenario. Download 40K, abort after 20K, resume, abort at 30K, resume, abort at 39K, resume, done. The user was counted for 20+30+39+40=129K and not 40K. This is fixed; ■ Errorlevel uploads could be counted as wrong when an exit was called after the upload. This is fixed; ■ The problem with MinSpace is fixed at last (I hope). Both the inter- nal coding AND the method are changed. I now use a faster method and will also be able to cover more type of drives (RAM-disk, LAN drives, SUBST-drives, ASSIGNed drives and such); ■ There is a flaw in some BBS programs that causes FileDoor to display a very large number for the remaining download-credit. This is the case when the downloaded KB's is set higher than the limit (by the Sysop). This causes the reversed to happen. This is NOT a problem of FileDoor but a problem of the BBS that passes the wrong value to the door. A message is send to the author(s) of those BBS's; ■ When there is no specific log-file present (all 3 types) and there is nothing to add also, FileDoor would create a log-file with a 0 byte length. This is fixed; ■ The special upload/download log contained the name of the day and not the month. This is fixed; ■ For SBBS users, the name of FILES.SBS is changed in FLSEARCH.CTL; ■ Clarified the search for FileDoor.CFG in the documentation; ■ Fixed a problem with the sharing of FILES.RA (and alike) files; ■ Fixed a problem with the sharing of HLP_*.* and MNU_*.* files; ■ The ASCII help-files could not be found. This is fixed; ■ Fixed various errors with errorlevel/other protocols and download; ■ Fixed the calls to various protocols (Bimodem to name one); ■ LHA archives with level-2 headers would not be detected. This is fixed; ■ If -U is present on the call to FileDoor (and also -P, see later), FileDoor will not check any UploadPath (PUploadPath) option in FileDoor.Cfg for valid data; ■ Using // in the wrong way caused the previous selection (or trash) to be displayed on the display. This is fixed; ■ After the selection of the protocol, FileDoor will now send a clear-screen so there will be no trashed screen at the user side; ■ Added the NOEMS and NOXMS options; ■ Added PUploadPath (and -P) to move private uploads to a different directory than the upload-directory (if wanted); ■ Did a complete facelist to the file-selection. Added /Q, /S to be used by the user and ExactMatch and QuickMatch to be used by the Sysop. See the new chapter for a discussion on the file- selection; ■ Changed the support for //. There will be a separate question for the password and this password is protected on-screen with '*'. ■ Added AlienArchive option to point to special types of archives that FileDoor has no knowledge of. ┌───────┬────────────────────────────┐ │ 2.03 │ 'Minor' and bug release │ └───────┴────────────────────────────┘ Be prepared for a long list of bugs, changes and features. It took some time to create the new version so many user requests could be implemented (others are implemented in 2.10, the next release). The basic idea behind this release is to fix the real problems and to add some small gigs. A small line in this list can make your day (or it won't) !!! ■ Fixed the flag-support. It now works like the BBS. This should be a relief; ■ Fixed the CTRL-Z problem that caused the FILES.BBS to trash and make some editors go wild. Also the uploads will be logged in the FILES.BBS ok (and no trash); ■ Fixed the hangup in FileDoor that was caused when a user used the Bimodem <tm> protocol (registered or hacked) and added some files to download. It could result in hanging FileDoor, hanging multi- tasker, hanging machine or other strange things (I was trashing the PC's memory); ■ Fixed the problem in multi-line operations with the 'SYSTEM FILE (FILES.RA) NOT FOUND' error. I was sharing the file (thank you folks, I received as many 'It is sharing-code 64' messages as I got registrations) but forgot the sharing in one S.O.B. part of the program (a removed line); ■ Fixed the problem where users were removed from FileDoor for no reason with the CARRIER LOST or TIMEOUT/LOCKOUT message. This was caused because of a weak filer in the input; ■ Fixed the problem where users could enter control-codes in the input lines (same weak filer as above); ■ Fixed the problem where users would enter a file to upload twice (or more) in the pre-selection, sending them once, and FileDoor counting it twice (or more); ■ Fixed the problem with the RC=2 error when the protocols were in the current directory when FileDoor got control; ■ The input-buffer was not cleared so when the user pressed 'Y' or 'N' to hard, they got more ('Y') or less ('N') files than they wanted. Now the buffer is cleared before the next question; ■ With QuickMatch on, it was possible to enter *.* or ????????.???. This is now filtered as a wrong file-mask; ■ Changed the user's command-line. The '[CR] to start download' will only be presented when a file is selected (excluded is the infor- mation file, see later) or when Bimodem is used; ■ Added the DupePath option to allow the movement (and not delete) of duplicate files to a special directory; ■ Fixed a bug where FileDoor was counting IMb+ files as one tenth of their actual size; ■ Fixed a bug where FileDoor was not seeing duplicate files when the BBS was using ARJ for most files; ■ Reconfigured the logging (see documentation). It is important to take some time to add the new features OTHERWISE LOGGING WILL RE- SULT IN EMPTY LINES IN YOUR LOG !!!!!!! ■ Dupe files (upload) can now also be logged (see documentation); ■ Made the selection display somewhat smaller and added an option for the user to read extended information about a file. This will include the comment (up to 250 bytes, QFV/F/C +-commentline com- patible), the name of the area, the size, the date and the time; ■ Enhanced the Color option with some colors that could not be changed. Now they can; ■ Fixed 80% of the FOSSIL routines, causing less ticks to be snatched from your other task(s) (under multitasking); ■ Added a Debug option; ■ Added a HelpExitKeys option; ■ Added a NotAvailText option; ■ Added the ExitAfterDownload option to call an exit after the down- load; ■ Added information-file options. The user can now also download a file with comments of the (previously) selected or downloaded files EVEN with protocols that allow only 1 download at any time. If the user stays in FileDoor, the info-file is kept and can be downloaded UNLESS the user exits from FileDoor. Added the option DownloadInfo; ■ If the user selects <G>oodbye after transfer, FileDoor will now display the GOODBYE.A?? screen; ■ If the user tries to download outside the normal hours, FileDoor will display the DNLDHRS.A?? file; ■ If the HLP_???? file is not present, FileDoor will try to display XFERHELP.A?? (if present); ■ Fixed a bug where FileDoor could leave the temporary directory after a transfer. This is fixed; ■ Added some space to allow up to 255 protocols PER direction BUT remember that the screen will scroll and every protocol will take up to 172 bytes of memory; ■ Added ANSASC option to use different names for the menus and help- files; ■ Added explicit support for SBBS 1.11 and up (FLSEARCH.BBS); 5.4 Copyright, Trademarks ──────────────────────────────────────────────────────────────────────── Bimodem is a trademakr of Eric Labs 4Dos is a trademark of J.P. Software / R.C. Conn and T. Rawson FrontDoor is a trademark of J. Homrichhausen SBBS is a trademark of Risto Virkkala and Aki Antman MSDOS is a trademark of Microsoft(tm) Windows is a trademark of Microsoft(tm) QuickBBS is a trademark of the QuickBBS group Inc. Remote Access is a trademark of Continental Software FileDoor is written in Turbo Pascal 6.0, with help of the Turbo Debugger 2.0 and makes extensive use of Object Professional 1.11 and OPCFI 9.21. Also included are some routines of Blaise's fine PowerTools Plus 5.1, the SYSTEM.TPU is replaced with a registered commercial release of SYS60a and also STRG61 (registered, commercial) is included. Turbo Pascal is a trademark of Borland International Turbo Debugger is a trademark of Borland International Object Professional is a trademark of TurboPower Inc. PowerTools Plus is a trademark of Blaise Computing Inc. OPCFI is a trademark of Robert W. van Hoeven SYS60a is a trademark of Eagle performance Software STRG61 is a trademark of Eagle performance Software ==================== END OF DOCUMENT ==================================