home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
move_106
/
maximove.doc
< prev
next >
Wrap
Text File
|
1993-12-27
|
5KB
|
122 lines
*** ** Maxi*MOVE 1.05<beta> by Erik Williams
** *** SunFox Productions, Ltd. <Durham, NC>
*** ** (c) Copyright, 1993. All rights reserved.
** *** "Jesus saves, Gretzky gets the rebound...SCORES!"
PRELIMINARY DOCUMENTATION
LAST MODIFIED: December 27th, 1993
FILES IN ARCHIVE:
MAXIMOVE.TOS => the executable
MAXIMOVE.CFG => config file...must be in Maxi*MOVE's directory!
MAXIMOVE.DOC => this documentation
INTRODUCTION:
Looking for an easy way to "upload" files that come in through the
AtariNet File Distribution System to your FoReM/Turbo v. 1.0 BBS
system?
Look no further...Maxi*MOVE is here! It will move those files to
the download areas you wish, put up the appropriate description in
the .DIR file, and your users will have immediate access to the file.
CONFIGURING THIS BUGGER:
Configuring Maxi*MOVE to do as you wish is relatively simple...MAXIMOVE.CFG
is pretty much free-format in terms of spacing...feel free to indent as you
wish...Maxi*MOVE's parser isn't fazed by block-style lines. In fact, I
highly encourage a block-format...it makes reading and fixing the config
file that much easier! A sample of this is the MAXIMOVE.CFG I have
included in this archive.
REQUIRED CONFIGURATION LINES:
LogFile <path and filename of log>
ex. LogFile g:\logs\maximove.log
LogFile is simply the path and filename that you wish the logging to
be written to. I use the standard Binkley logging format, so you can use
your main log or one of your choosing...either way is fine.
SysopName <your name>
The SysopName parameter will be the one used for the Uploader field
in the download area.
FileAppCode <number>
The FileAppCode is the line number of the application type you wish
to have displayed. These application types are located in a flat ASCII
file called FTYPE.LST. Edit FTYPE.LST and put your special "AFDS Maxi*MOVE"
or similar message in it...and then use the line number of that message
as the parameter for FileAppCode.
FileASCII <A|B>
FileASCII will either be A for an ASCII file or B for binary files.
I recommend that you leave it as B as I don't currently allow for
individual areas to get individual FileASCII definitions. That may come
in a later version if there is enough interest.
FileLevel <user level>
This is the level of access you wish to give to the moved files...a
user that wishes to see them must be equal to or greater than this level
to download the files.
CopyFiles
This directive tells Maxi*MOVE to simply copy the files and not
delete them after they have been copied.
MoveFiles
This directive tells Maxi*MOVE to MOVE the files which is a delete
after they have been copied.
ConfigDAT <path and filename>
This is the full path and filename for your CONFIG.DAT...it is read
to get the last file number and to update the number of files in system
if a file is moved.
MoveDLs <source path> <destination path>
This is the meat of the configuration...all I need is the AFDS
holding path as your source and the FoReM/Turbo directory path where you
want the files to be "uploaded".
What will happen is that Maxi*MOVE will check the source directory
for a file called FILES.BBS...which is the file written by STick/Hatch or
AutoFile after a file has come in through AFDS. Make sure that you
configure STick to write the FILES.BBS files (AutoFile will do it
automagically)! It will also check the destination directory for a file
ending in .DIR which is the data file holding all of the information for
a particular download area.
If both of these files are there, then it reads FILES.BBS one line at
a time, picking out a filename and a description. It checks to see if that
file is already in the destination area (in other words, it does some
dupe checking) and that the file is still in the source directory (i.e.,
you haven't moved it or deleted it!). If all is well, it will copy it to
the destination and add the FoReM/Turbo information to the .DIR file.
Maxi*MOVE will keep doing this until the FILES.BBS file is exhausted.
It then moves on to the next area and does the same thing until there are
no more areas left.
FINAL COMMENTS:
That should about do it...admittedly, the code is still a bit rough, but
in weeks of testing, it's done the job here. It works on the TT030 and
should work on a Mega4STE.
Any comments/bug reports you may have, please let me know so I can fix them.
I'm usually in Fayetteville (NC) on the weekends...
SunFox