HINTS
(Some additional information)
■ Place the executable and the config file in your path. That will
insure that you will be able to call FDSecure from any directory
or sub-directory at any time. This is especially usefull when
you are using the query mode, such as FDSECURE <FileName>.
■ FDSecure's internal code for moving a file to another directory
is very good. I would suggest using it over an external program
because it uses less memory, and is integrated. You can, however,
in place of EXTERNMOVE <ProgramName> <DPN> <DPN>, you could put a
batch file there, and the two parameters would become %1 and %2
in your batch file. i.e. EXTERNMOVE <Filename.bat> <DPN> <DPN>.
The first being FROM and the second being the TO fields.
If you use the internal move code, FDSecure has the ability to
detect if a file cannot be moved. i.e. an improper directory was
specified or the directory name has changed. If this should happen,
FDSecure will rename the file to have the extension of .BAD. It
will then proceed to write you a message as normal except it will
tell you that a problem occured in moving a file, and it suspects
an improper directory or something. Obviously FDSecure cannot
provide you with this protection when you use an external program
since it has no way to determine what errorlevels are returned from
the other program, and what the intention of the sysop is with the
file(s).
■ Check your FrontDoor log file. FDSecure will log anything that
happens in there as well as any errors if it should encounter them.
■ If you are having problems with FDSecure reading the config file,
then first make sure the config file is called FDSECURE.CFG. If you
have it under a different name, then you must use the /C option
to tell FDSecure you are using a different config file.
■ Max security feature. If a file appears in your inbound directory
and is NOT listed in your FrontDoor Log file, and is listed as a
target file in your FDSecure Config file, FDSecure will move it and
the netmail message will say the file came from -unknown- origin.
This gives you a little added security. FrontDoor presently does
not log partial transfers. Therefore, if you were to start recieving
your Nodediff from your Hub, and the transfer was interrupted at
60% transferred, then your batch file would see the nodediff file
in your inbound directory and attempt to process it. This may or
may not be a problem for some. FDSecure would see the file, check
the log, and by not finding the file in the log, would move it to
your bad directory-- thus avoiding a potential computer hiccough.
This can be disabled by commenting out the Move_Unlisted feature
in the config file. Commenting this out will tell FDSecure to
ignore target files in which FDSecure can't tell where they came
from.
■ If Fdsecure appears to not be reading the Log file correctly, be
sure and check your level of verbosity in the log. FDSecure
needs the information in lines preceeded by a plus (+). This
is the minimum level of verbosity required. Additionally, FDSecure
will use the information provided by the tilde (~) level for extra
information when reporting findings from the log. Obviously, the more
files you check for, and the greater the size of your log file, will
have a proportional effect on FDSecure's speed. But, no matter how
many entries or filenames you are looking for, FDSecure will only
have to read your log file one time.