Category : BBS Programs+Doors
Archive : XFD_202.ZIP
Filename : XFDDOCEN.DOC
Output of file : XFDDOCEN.DOC contained in archive : XFD_202.ZIP
º XFD ³ D.I.S.P. ³ÄÄÄÄ¿
º FileDoor (tm) ³ ³°°°°³
ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³°°°°³
º (c) 1991 Robert W.van Hoeven ³ Dutch ³°°°°³
ÇÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ Independent ³°°°°³
º Release : 2.02 ³ ShareWare ³°°°°³
º Rel.Date: 12th May 1991 ³ Programmer³°°°°³
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ°°°°³
º Documentation | ³°°°°°°°°°°°°°°°°°³
º (c) 1991 Reinier E.B. de Groot | ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
º | ÚÄÄÄÄÄ¿ |
º '³' will show the changes in | ³°°°°°³ |
º this version. These are | ÀÄÄÂÄÄÙ |
º the changes to version 2.01 | ÚÄÄÄÄÁÄÄÄÄ¿ |
º and found in column 1 of ------³³³³³³ ÍÍͳ-------
º the document ! ÀÄÄÄÄÄÄÄÄÄÙ
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ
º 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 Basic statements
3.3.2 Statements that define the environment that FILEDOOR uses
(paths)
3.3.3 Other statements, not related to protocol definition
3.3.4 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
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
- Problems and suggestions can be entered in the FidoNet
conference
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.
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
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
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 )
For zone 3,4,5 and 6 (vacant )
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
between Van and Hoeven) at 2:512/100 or (better) 2:512/100.5;
- A Message in the FidoNet
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
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.
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 200K 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
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
FileDoor
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.
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 current version you own (XFD_V201) 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.
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.xx 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 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.
- all those options not found in any BBS program or any other
transfer interface.
ÚÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 3 ³ Installation description ³
ÀÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
3.1 Installation (general)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Before installing you MUST read this DOC file and the README.1ST file,
which will contain last minute addendum. 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.
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);
- 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;
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 -N[line] -DD -A[DownloadPath] -C[cfg file]
The -A switch may be omitted when you have the AutoSearch feature enabled.
This is also the case for -N if you run a single line BBS or use the
BBSLine option in FileDoor.Cfg.
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 -N*N -DD -CFILEDOOR.CFG -AC:\BBS\FILES\DISP *M
The *N option will pass the nodenumer to FileDoor. The *M will swap a
large part of RemoteAccess to EMS/Disk.
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 -N[line] -DU -U[UploadPath] -C[cfg file]
The -U switch may be omitted when you use 'UploadPath' in FILEDOOR.CFG.
This is also the case for -N if you run a single line BBS or use the
BBSLine option in FileDoor.Cfg.
FileDoor will use all BBS program specific files like FILES.RA in
RemoteAccess 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 -N*N -DU -CFILEDOOR.CFG -UC:\BBS\FILES\DISP *M
The *N option will pass the nodenumer to FileDoor. The *M will swap a
large part of RemoteAccess to EMS/Disk.
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 -N[line] -DB -U[UploadPath] -A[DownloadPath]
-C[cfg file]
The -A switch may be omitted when you have the AutoSearch feature enabled.
The same goes for -N and -U like you saw in the download and upload
chapters.
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 -N*N -DB -CFILEDOOR.CFG *M
(AutoSearch enabled and UploadPath in Filedoor.Cfg)
The *N option will pass the nodenumer to FileDoor. The *M will swap a
large part of RemoteAccess to EMS/Disk.
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 !
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 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.
[path] must contain the complete path to FILES.RA (RemoteAccess),
FLSEARCH.CTL (QuickBBS) or FILES.SBS (SuperBBS). When running
with QuickBBS 2.75á, you must still use the old FLSEARCH.CTL
format, but the new format is included in FileDoor version 2.02
and up.
Example : System RA1 D:\BBS\RA\FILES.RA
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 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.2 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. These are:
³
³ 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
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ LogFile [path] {option} ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Usage : Choose the logfile for logging all Filedoor activities.
RemoteAccess users may add the type logging (e.g. OPUS for
OPUS-style of log or FRODO for FrontDoor-style of log).
This is only allowed when the SYSTEM is set to RA0 or RA1.
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 OPUS
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 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.3 Other statements, not related to protocol definition
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ Color [lowmenu] [highmenu] [attention] [statusbar] [errors] ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
Usage : You can overrule the default colors to make FileDoor look
more the way your own BBS looks. There are 5 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] and the color
of the errors [error].
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 (to define a 'green-based' FileDoor)
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 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).
³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³³ 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.
³
³
³ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³³ ExactMatch ³
³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
³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
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ 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.4 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
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
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
FileDoor can use a FileDoor/DISP-compatible tag-file
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.
5.4 Copyright, Trademarks
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
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.20.
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 ==================================
Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!
This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.
But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/