Beijing Paradise BBS Backup

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

/ Beijing Paradise BBS Backup / PARADISE.ISO / software / BBSDOORW / FM_3103G.ZIP / FILEMGR.DOC < prev next >

Wrap

Text File | 1992-12-31 | 145.5 KB | 3,818 lines

FileMgr GAMMA FileMgr, the ultimate file processor USER GUIDE Software and documentation written by Erick van Emmerik copyright (c)1992,93 by Erick van Emmerik MADE IN HOLLAND Changes to this document are expressly forbidden FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── TABLE OF CONTENTS 1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 What is FileMgr? . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 LICENSE AND DISCLAIMER . . . . . . . . . . . . . . . . . . . . . . 6 2.1 License . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 TECHNOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 File distribution, the *.TIC . . . . . . . . . . . . . . . . 7 3.2 Packed *.TIC files. . . . . . . . . . . . . . . . . . . . . . 8 3.3 Splitting or joining areas . . . . . . . . . . . . . . . . . 8 3.4 FileFind/'AllFix' requests, locating files through echo- mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 Mail Robots . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 INSTALLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Tips for upgrading from Tick/Raid . . . . . . . . . . . . . . 12 4.3 Tips for upgrading from AllFix . . . . . . . . . . . . . . . 12 5 FMSETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 General information . . . . . . . . . . . . . . . . . . . . . 14 5.2 System data . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1 Addresses . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2 AKA matching . . . . . . . . . . . . . . . . . . . . 15 5.2.3 Site info . . . . . . . . . . . . . . . . . . . . . . 15 5.2.4 Paths & filenames . . . . . . . . . . . . . . . . . . 16 5.2.5 Archivers . . . . . . . . . . . . . . . . . . . . . . 18 5.2.6 Miscellaneous . . . . . . . . . . . . . . . . . . . . 19 5.2.7 Origin lines . . . . . . . . . . . . . . . . . . . . 22 5.2.8 Aliases . . . . . . . . . . . . . . . . . . . . . . . 22 5.3 Group manager . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Area manager . . . . . . . . . . . . . . . . . . . . . . . . 24 5.5 Node Manager . . . . . . . . . . . . . . . . . . . . . . . . 29 5.6 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.7 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.8 FileFinder . . . . . . . . . . . . . . . . . . . . . . . . . 42 5.8.1 File areas . . . . . . . . . . . . . . . . . . . . . 42 5.8.2 Message areas . . . . . . . . . . . . . . . . . . . . 42 5.8.3 Miscellaneous . . . . . . . . . . . . . . . . . . . . 44 5.9 Message manager . . . . . . . . . . . . . . . . . . . . . . . 45 5.10 Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.11 Export . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6 FileMgr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.1 General Information . . . . . . . . . . . . . . . . . . . . . 49 6.2 Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.3 Mgr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.4 Announce . . . . . . . . . . . . . . . . . . . . . . . . . . 51 6.5 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.6 FileFind . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.7 Notify . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.8 NewScan . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 2 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 6.9 Hatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.9.1 Interactive hatch . . . . . . . . . . . . . . . . . . 53 6.9.2 Commandline hatch . . . . . . . . . . . . . . . . . . 54 6.10 Using FileMgr's parameters . . . . . . . . . . . . . . . . . 55 7 HSCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 8 TEMPLATE FILES . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.1 Overview of available keywords in template files. . . . . . . 57 8.2 Overview of available formatting commands . . . . . . . . . . 58 9 CREDITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 9.1 Copyrights and trademarks . . . . . . . . . . . . . . . . . . 60 9.2 Thanks, thanks.......THANKS! . . . . . . . . . . . . . . . . 60 9.3 Registration and support . . . . . . . . . . . . . . . . . . 61 3 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 1 INTRODUCTION 1.1 What is FileMgr? FileMgr does for files what an echomail-processor does for messages. Just like EchoMail, files can also be distributed in areas. The major advantages of this are a.o. that files are automatically placed in the correct directory on the BBS, can be announced in the correct echomail area and that people can connect and disconnect themselves from such an area so they will only receive the files they are really interested in. The program Tick introduced the so-called TIC-files. TIC-files are sent with a file and contain the information about that file, like the name, the description, the area and information for the routing. Tick uses that information to move the file to the correct directory and to forward it to the systems that are connected to the area in question. FileMgr too makes use of the TIC-concept. FileMgr however offers more. It has possibilities to give files a special treatment, automatically start batch-files, announce received files, allow systems to connect and disconnect areas and much more. The first version of FileMgr was made in september 1991 as an alternative to Tick and Raid. In the mean time it has developed into the most complete file processing package and it has over a hundred registered users in the Netherlands, Belgium, Germany, Sweden, Switzerland, Italy, the UK, the USA, Australia and Hong Kong. 1.2 Features The possibilities of FileMgr are too numerous to mention them all. Still, for new users a short list of the most important features. - 4D zone/point support - Allows use of more than one AKA, with optional AKA matching - Incoming and outgoing mail through Hudson messagebase or in *.PKT- format which can be used by virtually any messagebase-format. - Possibility to pack *.TIC-files and the files themselves, choosing your favorite archiving program. - Very user friendly setup-program, full screen using windows and menus. - Supports XMS-, EMS- and disk swapping. - Powerful and user friendly 'AreaMgr'-alike interface for downlinks. - Creates areas automatically. - Supports 'MAGIC' file-request names. - 'AllFix' compatible filefind-feature allowing replies in the same or another echomail area or even by NetMail. 4 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── - Very powerful and highly flexible template-engine, which can be used for creating announcements, filefind-replies and the descriptions in your FILES.BBS or equivalent. - Excellent dupe-checking on name, size and CRC-32. - Possibility to adopt files in a certain area, move files to a different area, make extra copies of a file etc. - Possibility to execute certain tasks at a desired moment, like weekly hatching a certain file, monthly posting of a message etc. - Supports a maximum of 1024 file-areas with 0 to 255 downlinks each. - Automatic hatching or only announcing of files that are new on the BBS. - Hatching can be done either from the command line or by using the full-screen hatch-menu. 5 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 2 LICENSE AND DISCLAIMER 2.1 License - All FileMgr executables and documentation are copyrighted material by Erick van Emmerik. - Beta-versions of FileMgr can be used by registered users of FileMgr, with permission of the author, until release of FileMgr 1.00. - FileMgr may not be used in a commercial environment like companies, schools and other institutions without prior permission of the author. 2.2 Disclaimer The use of FileMgr is at your own risk. The author of FileMgr, Erick van Emmerik, accepts no responsibility for any damages resulting from the use of FileMgr nor directly, nor indirectly. The author does not guarantee the functionality of the FileMgr program. 6 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 3 TECHNOLOGY This chapter assumes you are familiar with the structure and terminology of the FidoNet Technology Networks (FTN) and echomail processors. 3.1 File distribution, the *.TIC-concept Sending a file from one fido-system to another can be done many ways. The most simple way to do this is to create a so-called file-attach message. For one-time transfers this is a very usable method. As soon as files have to be transferred on a more regular basis (like NODEDIFF.* files) this method will prove to require much work and attention. Automization of the process is in order. If a file needs to be sent every week, for instance, one can make use of a so called 'file-robot'. This is a program, or a part of a program, that offers the possibility to send a certain file to another system regularly, for instance once a week. If files are being received from another system regularly, other software might be useful. Based on a standard DOS filemask (for instance NODEDIFF.A*) such a program can determine the file was received and take certain actions as a result thereof. These actions might include moving the files to a different directory (a directory that is accessible for download on the BBS), sending the file to yet other FidoNet systems, adding a standard description for the file to a list-file (for instance 'Weekly FidoNet NodeList update') and the execution of an external program, for instance to update the NodeList. The method as described here works perfectly for files of which you can determine in advance what name they will have and what description they should get. As soon as you receive files of a wider variety this method doesn't suffice. A different, more advanced method of sending is the use of a small accompanying text-file, which can contain various information about the file in question. At this moment this method is widely used in FidoNet Technology Networks. In this case we use files that have *.TIC as extension. Let's look at an example of a *.TIC-file: Created by FileMgr BETA, (c)1991,92 by Erick van Emmerik (2:281/611) File NODEDIFF.A97 Desc Nodediff for day 297 Area NODEDIFF Origin 2:281/1 From 2:281/1 Path 2:281/1 720101091 Mon Oct 26 10:04:51 1992 UTC Seenby 2:281/603 Seenby 1:281/200 Seenby 2:281/611 Pw YOYO As you can see the *.TIC-file contains not only the name and the description of the file ('Name', 'Desc'). Additional information is 7 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── given about the system that originally released the file ('Origin'), the system that sent the file to your system ('From') and the systems that already received the file ('Path' and 'Seenby'). You can also send a password in the *.TIC-file ('Pw') so your system can verify that the file came from the correct feed. One of the most important parts however is the area in which the file is being sent ('Area'). Using this one can group certain files and give them a special treatment. This way you can easily determine what kind of file it is (for instance a piece of Pascal source, a nodediff or an OS/2 file) and this enables you to only send the file to those systems that are really interested in it. All this information enables the receiving system to know exactly what to do with the file. Obviously this is a very pleasant way of working for the SysOp. FileMgr offers the SysOp the possibility to maximize the utilization of this method, but is also capable of working as a 'file-robot'. 3.2 Packed *.TIC files. Since *.TIC files are relatively small, and each file has it's own accompanying *.TIC-file, the overhead in this system is rather large. Just think of it, for each *.TIC-file a file-attach must be made and on large systems with many downlinks this can lead to unacceptable results. Therefore a number of programs offers the possibility to pack these *.TIC-files and the main files themselves into one big archive- file. A program like TickPack uses it's own compression method to do this, other programs use regular archiving software like the PKWare programs. Some programs pack just the *.TIC-files, others allow all outgoing files to be packed. FileMgr gives you the possibility to specify whether or not the *.TIC- files and/or the main files must be packed per node. For each system you can specify which of the four most used archiving methods (ARC, LHA, ZIP or ARJ) should be used. FileMgr will automatically unpack all received bundles. Obviously all methods used will be supported providing you have the appropriate de- archivers in a directory which is on your DOS-path. 3.3 Splitting or joining areas Sometimes the feed in a certain area is so large that systems with a slow modem or little HD-space won't be interested anymore in receiving such an area. Also, the files of a certain area can be so diverse that simple point would be forced to receive files they would almost certainly delete immediately. Another problem is that you may receive several areas that contain the same type of files. In such a situation you might easily loose overview of what is arriving at your system. 8 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── To cope with this kind of problems FileMgr offers various possibilities, many of which are not available in any other package. FileMgr can move files, based on a filemask, to a different area. This enables you to split large areas up and create specific areas. Also this option allows you to join areas together. Furthermore you can make an area 'pass-through', decide not to send files or copy files to a different directory, all based on area and filemask. FileMgr also offers you the possibility to adopt a file which didn't come with a *.TIC-file into a certain area based on a filemask. 3.4 FileFind/'AllFix' requests, locating files through echomail Echomail is a system to send messages to all other systems in a network. FileMgr can use echomail to allow users to locate files on other systems. Suppose you are looking for a certain file. Normally you would need to call a BBS and look whether they have that file. If you can't find the desired file, which will happen quite often, you would have to continue you search. This can take much time and money when there is an easier method. Suppose you are looking for the program RemoteAccess. You have a general idea of the name, but you don't know where to find it. Using the FileFind you enter a message in an echomail conference which is meant for that subject. You address the message to 'AllFix' and on the subject line you enter one or more search-keys. You can specify a filemask, but you can also use a keyword. Keywords should be preceded by a '/'. An example of such a message: Fr: Erick van Emmerik To: AllFix Re: RA_???.* /remoteaccess -------------------------- This message will be sent to various other systems, that's why it is an echomail message. All systems that have FileMgr (or another program that supports this) installed will receive this message. Subsequently on that system FileMgr starts searching for the files that match your specifications. If one or more files are found, FileMgr will send a reply message containing the names and descriptions of the files that were found, together with some additional information about the system where the files were found. This reply message can be sent either through netmail or through echomail. This concept was first implemented in the program AllFix by Harald Harms. That is also the reason why we speak of 'AllFix'-requests, even though the feature is called 'FileFind' in FileMgr. Apart from FileMgr and AllFix there are also other programs that support this method of locating files. 9 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Requests can be offered to FileMgr in two ways. Directly in a Hudson- type messagebase (=QuickBBS), or by use of packets (*.PKT-files). The reply messages created by FileMgr can also be sent in these two ways, or through NetMail. The latter can be used to reduce a large flow of reply messages in an 'AllFix'-conference. As far as I know, however, FileMgr is the only program that is capable of sending it's reply messages through NetMail. FileMgr can also send it's reply message in another area than the one the original message was found in. 3.5 Mail Robots Just like you have files that need to be sent regularly, there are also messages, NetMail or EchoMail, that need to be sent on a certain regular basis. Here you can think about the rules of an EchoMail conference, a list of so called 'frequently asked questions' etc. FileMgr supports this too. It is very well possible to post the rules of a conference that you moderate once a month, or to send someone a NetMail message with a certain content once a week or once a fortnight. Obviously this opens up possibilities to further automize you system. 10 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 4 INSTALLATION 4.1 General It is advised to reserve a separate directory for FileMgr. In the remainder of this manual we will assume that all program-files are located in the directory C:\FileMgr. I also advise you to make some more directories, specifically: C:\FileMgr\OUT To store files that are on 'hold'. FileMgr can keep this directory 'clean' itself. This means that files that have been sent will be removed from that directory. C:\FileMgr\BAD To store bad files, like files that are incomplete or files in an unknown area. C:\FileMgr\TPL To store the so called template files. These files are used by FileMgr to create messages. It is convenient to keep these files in a separate directory. For convenience purposes it advised to include the FileMgr system directory in your PATH statement. Example: SET PATH=C:\;C:\DOS;C:\TOOLS;C:\FD;C:\FileMgr If you choose not to do this, you will need to switch to the FileMgr directory in order to be able to start FileMgr, or you will need to specify FileMgr's system directory on the command line. If is possible (but not necessary) to add the variable 'FileMgr' to your environment: SET FileMgr=C:\FileMgr This way, FileMgr will look for it's system file in this directory. Copy the following files to the FileMgr system directory: FileMgr.EXE FMSETUP.EXE HSCAN.EXE De-archive the file TEMPLATE.ARJ in the FileMgr template directory: ARJ E TEMPLATE.ARJ C:\FileMgr\TPL After you have completed this you can start the configuration program FMSETUP, and enter you configuration. 11 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── If you have been using Tick and/or Raid as a file-processor, please read paragraph 4.2. If you have been using AllFix before you switched to FileMgr, please read paragraph 4.3. 4.2 Tips for upgrading from Tick/Raid Since FileMgr offers more possibilities than the Tick/Raid programs, FileMgr needs more information to operate correctly. It is possible to import your Tick and/or Raid configuration files with FMSETUP, but we advise you to carefully consider the following items. FileMgr has a strong group-orientations. All areas in FileMgr are split up into groups. When importing you Tick configuration FileMgr can't find this group information because Tick doesn't support this concept. You can solve this problem by changing your Tick configuration-file. First you need to sort the areas in you Tick configuration file so the areas are grouped together they way you want them to. SDN areas together, SDS areas together a.s.o. Then BEFORE each group of areas you add the following line to you Tick configuration file: Group # Where the '#' sign is the group-ID. Example: Group S area c:\files\sds\sdsfront sdsfront 2:281/611 test *H 2:281/611 no *H area c:\files\sds\sdsbink sdsbink 2:281/611 test *H 2:281/611 no *H This tells FMSETUp you want these two areas to belong to group 'S'. Now it is much easier to enter the extra information that FileMgr needs for each area. BEFORE you import the Tick/Raid configuration file with FMSETUP, you need to define the necessary groups. As a last step you user FMSETUP to import your Tick and/or Raid configuration file, and you check the configuration. 4.3 Tips for upgrading from AllFix Because FileMgr offers more possibilities than AllFix, not all required configuration data can be imported from the AllFix configuration files. Some things are handled by AllFix in such a different way, that importing them makes little or no sense, this because most of the data would have to be reconfigured after all. 12 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── FMSETUP allows you to import the areas, groups and nodes from you AllFix setup into the FileMgr configuration. This alone will save you a lot of work in most cases. The AllFix configuration files that are used for the 'AllFix'-request function offer insufficient information to import them in a way that would make any sense to FileMgr. Entering this information in FMSETUP, however, is very easy for those of you who are used to AllFix. 13 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 5 FMSETUP 5.1 General information Before FileMgr can be used, several data about your system need to be entered. In order to do this you can use the program FMSETUP. This is a menu oriented program which is very friendly to the user. FMSETUP makes use of menus. You can move the selection bar up and down using the arrow-keys. Selecting a menu-item is done by pressing the [Enter]-key. If you want to back out to a previous menu, press [Esc]. In some cases FMSETUP will ask you whether you want to save the information you changed, or that the changes should be discarded. The bottom line of the screen is used to display a short help line concerning the option the selection bar is on. When entering or changing an item that specifies a directory, that directory may not exist. In that case FMSETUP can create that directory for you. It is also possible to create a directory more than one level deep all at once. For instance FMSETUP can create the directory C:\FILES\SDS\SDSFRONT even when C:\FILES does, but C:\FILES\SDS doesn't exist. From any screen in FMSETUP you can invoke a so called DOS-shell. You do this by pressing Ctrl-Z. You can do this to check something or look something up, without having to exit the program completely. Returning to FMSETUP is done by typing 'EXIT' at the DOS-prompt. FMSETUP can also be started with a command line parameter. This parameter is named 'PURGE', and is used to clean up the data files FileMgr uses. It is advised to do this regularly, especially if you create and/or delete areas regularly. 5.2 System data Here you can enter several general data about your system. In order to let FileMgr function correctly it is of the utmost importance that these data are entered carefully and correctly. 5.2.1 Addresses Main address Specify your main network address here. *.PKT address *.PKT password If you don't use a Hudson (QuickBBS) messagebase, you will need to make use of the so called *.PKT-interface of FileMgr for various functions. To this end it is necessary to specify a 'fake'-address, which will be used for FileMgr to create *.PKT files and when searching for and processing *.PKT files. This address must also be added to the configuration of your echomail processor. 14 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── You are strongly advised to choose an address of which it is very unlikely that it will exist somewhere in the network, for instance '99:9999/9999'. FileMgr also supports 4D point addresses at this point, but your echomail processor needs to support this too. As an extra measure of security it is possible to specify a password which will be used in the header of the *.PKT files. Specifying a password ensures that FileMgr will only process *.PKT files that contain the same password. The check for the password is case-insensitive. FileMgr will, in return, also use this password in the *.PKT files it creates. AKA #1 ... AKA #10 If you have more than one node number and want to make use of them, you can specify up to 10 AKAs 5.2.2 AKA matching If you are a part of more than one network, and therefore have more than one node number, the AKA matching feature might prove very useful. You can specify up to 15 combinations of zone- and netnumber with the network address to be used for that combination. FileMgr will use this AKA matching when answering NetMail messages, and optionally when sending *.TIC files. You can specify this for each area (ref. 5.4, Area Manager). 5.2.3 Site info SysOp's name Specify your full name here. For registered users it is important to know that this name needs to be exactly the same as the name FileMgr was registered for. System name Specify the name of your system. Here too the name must exactly match the name FileMgr was registered for. Registration code The GAMMA release of FileMgr requires the key '[EVALUATION]' to be entered here. Mailer type Normally FileMgr runs in FrontDoor mode. If you use Binkley or D'Bridge as your mailer software you can specify that here. In FrontDoor mode FileMgr will allways create *.MSG file-attaches. In D'Bridge mode FileMgr will directly write to the D'Bridge outbound queue. In Binkley mode FileMgr will create *.?LO files. If you use 15 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── the D'Bridge or Binkley mode, you need to specify a queu/ outboundpath. (see path & filenames -> Queue path) BBS type Specify the type of BBS-program that you use. If your BBS-program is not supported, please choose 'Other'. 5.2.4 Paths & filenames Inbound files Here you specify in which directory FileMgr should look for files that have just been received by your system. Usually it is the same directory that is specified in your mailer as 'inbound path'. Outbound files Here you specify a directory FileMgr can use to store the files that must be sent to other systems. It is advised to use a separate directory for this purpose (ref. 4.1). FileMgr also puts its *.TIC- files that are bound for other systems here. FileMgr will maintain this directory itself, which means that it will remove files that have been sent automatically. Netmail Here you specify the *.MSG NetMail directory which is used by your mailer. FileMgr will put the file-attach messages for outbound files here. FileMgr also uses this directory to search for messages addressed to 'FileMgr' from your downlinks. Finally, if you use the FileFind feature with the *.PKT interface, FileMgr will look here for ARCmail bundles addressed to the address specified as '*.PKT- address' in the section 'Addresses' (ref. 5.2.1). QuickBBS messagebase Here you specify the directory that contains your Hudson (QuickBBS) messagebase. If you don't use a Hudson-style messagebase you can omit this field. *.PKT-files If you wish to use the *.PKT interface this is where you specify the place where FileMgr should put its *.PKT files. Some EchoMail processors (like GEcho or FMail) offer you the opportunity to specify as special 'secure' or 'local' path. This indicates to the EchoMail processor that *.PKT files in this path should always be processed, even if the sender doesn't occur in the exportlist or when the address of the sender equals the addressee (your node number). If your EchoMail processor has this option it is unnecessary to specify a '*.PKT address', FileMgr can use your regular address instead. Bad files 16 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── This is the directory where 'bad' files are moved to. This can happen for various reasons. Generally the causes for this are an incorrect CRC, a wrong password or an unknown area. It is advised to use a separate directory here (ref. 4.1). AREAS.BBS Here you specify the location of your AREAS.BBS-file (or any other file with the same format). FMSETUP can use this type of file to make selecting message areas easier. An AREAS.BBS file is a plain ASCII-file, with the following setup for a Hudson-style (QuickBBS) messagebase: <line with system name or comment> ; <boardnr> <areatag> <downlinks> <boardnr> <areatag> <downlinks> .... etc. FileMgr uses the board number and the area-tag. For the *.MSG messagebase the layout of this file is slightly different, but this file can be used by FileMgr too. Specifying this file is optional, it is only meant to make your work easier and reduce the chance of errors. FileMgr's functionality is not affected by this option. Template path This is the place where FileMgr can find your so called template files. These are ASCII files that contain special keywords which are used to determine the lay-out of messages and descriptions. You can use the FileMgr system directory for this purpose, but it is advised to use a separate directory (ref. 4.1). On all occasions where you need to specify a template file, FMSETUP will offer you the possibility to open a window with a list of all available template files. This greatly enhances the ease of looking up template files and reduces the chance of errors. Since this list contains ALL files of the directory specified here, it is advised to use a separate directory. This way you are sure all files in the list are template files. Logfile name This is the location and name of the log file that FileMgr must make. FileMgr uses a FrontDoor-style log file. Quote file The messages that are created by FileMgr can be built using a variety of special keyword or macros. One of these template keywords allows you to include a one-line 'quote of the day' in a message. If you specify the pathname of a plain ASCII textfile here FileMgr will get its 'quote of the day' from that file. This is done at random. If you don't specify a quotefile, and use the appropriate keyword anyway, FileMgr will generate a quote itself, 17 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── which will usually be some kind of advertisement for the program itself :-). Magicname list 1 FileMgr allows you to update the file your mailer uses to know what 'magic' filerequest names can be used. These 'magic' names work according to the following principle. On your system a file is maintained with the following contents: FM_BETA C:\BETA\FM_2610B.ARJ FileMgr C:\FILES\FileMgr\FileMgr.ARJ Now, if a user enters a file request for the file FileMgr, your mailer will send the file specified above. This can be very useful for users who don't know the exact filename. FileMgr can maintain this list. This happens when a received *.TIC- file contains the keyword 'Magic'. FileMgr will then update the file specified here with the correct magicname and pathname specification. Magicname list 2 What applies to 'Magicname list 1' also applies to the file specified by the pathname here. The difference is that in this case the file will not be updated with the magic and the pathname of the file, but with the magicname and the description of the file. This 'Magic name list' can be used to inform your users about the 'magic' names that are active on your system. Queue path If you use FileMgr in D'Bridge mode this is where you enter D'Bridge's queue path. If you are using FileMgr in Binkley mode, this is where you specify Binkley's outbound path for the default zone. The default zone is defined a s the zone-number of your main address in FileMgr. (ref. 5.2.1) 5.2.5 Archivers In a number of cases FileMgr will use external archiving utilities such as PKZIP and ARJ, for instance to pack and unpack bundled *.TIC-files, to pack *.TIC-file bundles (ref. 3.2), and when using the *.PKT interface in combination with the FileFind feature, to unpack the ARCmail bundles. FileMgr supports the four most used archiving methods, specifically ZIP, ARJ, ARC and LZH (LHA). To be able to call these programs correctly, you need to specify in FMSETUP what the exact name is of these programs and what parameters should be passed to them. In most cases FMSETUP's defaults are correct and you won't need to change them. 18 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── ZIP : pkzip.exe -ea %1 @%2 pkunzip.exe -o %1 ARJ : arj.exe a -m4 %1 !%2 arj.exe e -y %1 LZH : lha.exe a /z2 %1 @%2 lha.exe a /m1 %1 ARC : pkarc.exe %1 @%2 pkarc.exe %1 For each archiving utility there are two columns, the left column specifies the call when compressing, the right column specifies the call for decompressing. There are two special parameters you need to use here. The first is '%1' which is substituted by FileMgr for the name of the archive file when it calls that program. This is used for both compressing and decompressing. When compressing files a second parameter is used: '%2' which will be replaced with the name of a plain ASCII textfile containing the filenames of the files that must be compressed into the archive. It is very important to understand this well, since specifying wrong or omitting necessary parameters will, especially when compressing, lead to very undesired results. Unpack When decompressing files, FileMgr uses the extension of a file to determine which program should be used. When for instance the file FM017D6A.ZIC is received PKUnzip will be used. If you don't trust this method, you can use a general unpacking program or shell, like for instance GUS. In that case you need to specify the name of this program and all necessary parameters here. Don't forget to specify the '%1' parameter at the appropriate place or your program won't know what to unpack, which is not very efficient :-) Output Here you can specify whether you want to see the screen output of the compressing and decompressing utilities. If you specify 'No' here, FileMgr will attempt to suppress the screen output of these programs. For unclear reasons it is not possible to suppress LHA's screen output. This switch has therefore no effect on LHA. 5.2.6 Miscellaneous Here you determine FileMgr's behavior at various points. It is advised to read this section carefully and set everything up according to your needs. Days to keep files Here you specify the number of days FileMgr should keep files that have not been collected by the receiving system. After that period, FileMgr will delete those files. This avoids the situation of your HD getting fuller and fuller that will never be collected. You should inform the SysOps of the systems you send files to about this setting, this to avoid unpleasant situations. 19 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Touch files Here you specify whether or not FileMgr should change the date of received files into today's date. This can be useful if you work with a BBS-program that can show your callers a list of new files, and when this list is compiled based upon date/time. FileMgr only changes the date of the file in your BBS-directory. Replace outdated files Received *.TIC files can contain the 'Replaces' keyword and the name of a file. This is used to replace an older version of a program with new one. This way you can prevent the situation that you have three versions of the same program in your directory; one correct version and two old versions. This is confusing and takes unnecessary disk space. With this switch you determine whether FileMgr will replace old versions of files when a 'Replaces' keyword is encountered. Kill received requests If this switch is set to 'Yes', NetMail messages addressed to FileMgr will be killed immediately after processing. If you set this switch to 'No', they will be marked 'Received'. Ignore unknown areas If this switch is set to 'No' and FileMgr receives a file in an area that doesn't occur in your configuration, this file, including its *.TIC file, will be moved to the 'Bad file directory'. If you set this switch to 'Yes', FileMgr will leave the file in your inbound path for later processing. This can be useful if you don't use FileMgr for all areas. This way you can let another program handle these areas AFTER FileMgr. FileMgr also has the possibility to allow systems that you receive files from to create new areas. In that case this switch is inactive, because the 'unknown area' is created immediately, and is therefore no longer unknown. Ignore bad CRC files This switch works similarly to the 'Ignore unknown areas' switch. If a file is rejected because the CRC-32 doesn't match the CRC-32 specified in the accompanying *.TIC-file, in virtually all cases that means the file is useless. Several causes can play a part here, most of which mean the file is not usable. It is therefore logical to move these files to the 'Bad file directory'. On the other hand it could be that the received file was not complete, for instance because the carrier got lost during the transfer. If this happens, and you call the system that you receive files from again, usually you don't need to receive the entire file all over again provide you use a modern transfer protocol. This is impossible when FileMgr has moved the file to the 'Bad file directory'. If this happens to you regularly you might consider setting this switch to 'Yes'. The files will remain in the inbound 20 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── directory of your mailer and FileMgr will check whether the CRC is OK each time over. In most cases however, it is advised to leave this switch set to 'No'. Force ^AINTL kludge The INTL kludge is used in NetMail messages addressed to someone in a different zone than your own. This kludge looks something like: ^aINTL <dest.addr> <orig.addr> Normally FileMgr will only add this kludge to messages of which the zone-numbers of addressee and sender are different. Setting this switch to 'Yes' will force FileMgr to add this kludge always. Update magic list This switch determines whether the 'magic' filename lists should be updated when FileMgr encounters a 'Magic' keyword in a *.TIC file (ref. 5.2.4). Weeks to keep history Of each file that is processed by FileMgr the name, size, area and CRC-32 are written to a history file. This file is used to check for duplicates; files that were received before and don't need to processed again. Here you specify the number of weeks FileMgr should keep the entries in the history file. It is advised to keep this value as high as possible. Max. size of history The maximum size in kilobytes the history file may get. See previous item for more information. Area sorting method With this option you can determine in what order the entries in the Area Manager (ref. 5.4) will be sorted. The options are TAG or GROUP. The latter is usually easier. UTC difference The 'Path' lines in a *.TIC file also mention the time and date a file was processed. This time should be displayed as UTC (GMT) time. In order to correctly calculate the UTC time from your system time, FileMgr needs to know how much difference there is. Here you enter the number of hours FileMgr should ADD to your local time to calculate UTC. Default password FileMgr can send files to systems that are not in its configuration. This doesn't give many problems, the file-attach will be addressed to 'SysOp', and as long as the address is in 21 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── order, the file will arrive. The only problem is the password that is mentioned in a *.TIC file. In such a case the password is unknown. Omitting the field after the 'Pw' keyword, or even omitting the 'Pw' line completely will not always be accepted. The password you enter here as 'Default password' will be used in the *.TIC file in these cases. 5.2.7 Origin lines Here you can enter up to ten origin lines which can be selected in either the FileFind menu (ref. 5.8) and the Message manager (ref. 5.9). 5.2.8 Aliases Do you know them too? SysOps who, even though you told them at least three times over, keep addressing their messages to Raid, when you have stopped using that program weeks ago. Make it easy on them. Here you can enter up to 10 different names that FileMgr will recognize as messages to itself. You can use the '*' wildcard at the end of a name to indicate anything starting with that name should be recognized. A couple of examples: #1 : FileMgr* #2 : RAID #3 : FILEFIX This makes sure that messages addressed to anything starting with 'FileMgr' as well as messages addressed to 'RAID' and 'ALLFIX' will be processed by FileMgr. Name matching for this feature is case insensitive, which means that both 'raid' and 'rAiD' will be recognized in this example. 5.3 Group manager As already mentioned in paragraph 4.2, FileMgr is strongly group oriented. All file areas in FileMgr are grouped. The advantage thereof is that a lot of settings can be prepared per group. When creating a new area, automatically or manually, these settings can be copied to the new area as defaults. FileMgr allows system that you send files to, to connect or disconnect complete groups of areas with only one command. This eases the use greatly. Also where security is concerned the group-concept is important. Whether or not a certain system can or cannot connect itself to a certain area is determined by the fact whether or not it has access to the group the area belongs to. Announcing of new received files is also done on a group basis. Per group you can determine what EchoMail area the file should be announced in. 22 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Obviously groups are very important in FileMgr and defining them takes some caution and planning. The most logical method is defining a group for each file distribution network you are attached to. ID The 'ID' is used to refer to a group by the Area manager (ref. 5.4) and elsewhere in the program. The ID must be unique (which FMSETUP will check), and is one character long. You can use 36 different characters ranging from '0' to '9' and from 'A' to 'Z'. Description Here you describe the group in question. Where the ID is most important to FileMgr, you and your downlinks will most likely think of the description as the most important field. This description will be placed in the Area Manager (ref. 5.4) and in the lists that FileMgr can send to the connected systems and to yourself. This description can also be used when placing group-based announcements. Please be specific when entering a description, for instance 'PDN, Programmers Distribution Net'. Format *.TPL Directory List file Batchfile These items are meant to simplify creating new areas. As soon as you the group an area should belong to, FMSETUP will offer you to copy the above mentioned items (in addition to 'Default AKA and 'Status'). For a more thorough description of these items please refer to paragraph 5.4, Area Manager. Empty descr When you receive files in an area belonging to this group that don't have a description in the *.TIC file, the description you enter here will be used. Example: '[no description, inform the SysOp]'. Messages This field is very important. As soon as a file is received in an area belonging to this group, FileMgr checks whether you want to announce the reception. This can be configured per area (ref. 5.4, 'Status'). If that is the case, FileMgr needs to determine in which message area(s) the announcement must be placed. Here is where you enter that. To complicate everything: you cannot enter an area number or name here, but one or more message IDs. A message ID is something similar to a 'group ID', and refers to a message which is defined in the Message Manager (ref. 5.9). There you specify where exactly the message should be posted, in what form, with which origin address a.s.o. If you omit this field no announcements will be placed. Default AKA Status 23 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── These items too are for simplifying the creation of new areas. For a thorough description of these items, please refer to paragraph 5.4, Area Manager. Feed(s) Within one group, areas are usually collected from one system. Here you can specify that system as the 'official' group feed. Systems in this list are always allowed to send files in an area that belongs to this group, independent of the fact whether or not they appear in the 'export' list of such an area (ref. 5.4, 'Export'). 5.4 Area manager The Area Manager is probably the most important part of the FMSETUP program. Here you define all data concerning your areas. These data determine what FileMgr will and will not do with the files your system receives. Make sure you understand what influence various settings will have on FileMgr's functionality before you use them. Area tag This is a unique name that identifies the area. This name must be an exact match of the name specified after the 'Area' keyword in the *.TIC files your system receives. You can compare this with an EchoMail conference. Usually the system you receive files from allows you to request a list stating the exact tags of the areas you are connected to. An example of such a tag is 'PDNPASCL'. Description This description will, like the group description, be used in announcements and reports of areas. An example of a description could be: 'PDN pascal area'. Group ID Here you enter to which group the area belongs. A list of available areas will be displayed, so don't worry if you can't remember the group-Ids :-) As soon as you enter or change the ID, FMSETUP will ask you whether you want to copy the group defaults. If you answer this question with 'Y' the fields 'Format *.TPL', 'Directory', 'List file', 'Batchfile', 'Status' and 'Seenby' will be copied from the Group Manager settings (ref. 5.3). As soon as you have selected a 'Group ID' the appropriate description will be displayed. Format *.TPL When a file arrives on your system, the file will usually be copied to a directory on your BBS that is accessible for your users for download. Also a file (usually FILES.BBS) must be updated with the name and description of this file. Since not all BBS programs use the same type of file for this purpose, FileMgr allows you to define the layout of the entry that will be placed in this file yourself. To this end, you can use a so called template file, which is the same method that is used when announcing received files. You 24 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── can use special keywords in a template file which allows a very flexible layout. When your BBS uses the standard 'FILES.BBS' file, you can use the file 'FILESBBS.TPL' which is included in the TEMPLATE.ARJ archive. Other programs, like PCBoard, will require you to create your own template file. A detailed description of the format of these template files can be found in paragraph 8.1, Template files. Directory Here you enter the directory the files that are received in this area should be copied to. Generally this is a directory that is available on your BBS. As soon as the file is received and found OK, it is copied to this directory. List file Usually the 'FILES.BBS' file or its equivalent is located in the same directory specified at 'Directory' (see above). Some BBS software however uses a file with a different name, or even in a different directory. FileMgr supports this, so you can specify the exact pathname of that file here. If you enter or change the 'Directory' field of an area, FileMgr will ask you whether it should update this field with the new path. FileMgr will assume the list file is called 'FILES.BBS'. Batchfile FileMgr allows you to start an external program of batch-file when one or more files are received in a certain area. This can be useful to handle certain files. An example could be the NODEDIFF. Immediately after reception of a nodediff-file you can start a batch file that updates your nodelist and recompiles it. FileMgr passes three parameters to this batch file. The name of the file, the directory the file was copied to and the tag of the area the file was received in. You can test this by creating a simple batch file containing: echo %1 %2 %3 pause and specifying this batch file with this area. Status For each area a number of things can be switched on or off using these statusbits. If you copied the statusbits from the group data, and these are configured correctly, you will hardly ever need to change anything here. Announce 25 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── The 'Announce' statusbits determines whether files that are received in this area are to be announced. You do need to specify the correct message IDs at the 'Message' field in the Group Manager (ref. 5.3) and you must also define the messages in the Message Manager (ref. 5.9). If this bit is set to 'No', files in this area will never be announced, even though you may have defined messages in the Group Manager. Backup If you yourself forward files in this area to other systems, a so called file attach must be made. This file attach must also contain the location where your mailer can find the file that must be sent. If the 'Backup' statusbit is set to 'No', this is the same directory as the directory you specified at the 'Directory' field for this area. This can however be risky if you regularly clean up your BBS directories and also delete recent files in the process, for instance because they are of no importance to your BBS. If you accidently delete a file that still has to be sent to another system the SysOp of that system will be in for an unpleasant surprise; the file has vanished. If you want to prevent this, you can set the 'backup' statusbit to 'Y'. This will cause FileMgr to make a copy of outbound files in FileMgr's outbound directory (ref. 5.2.4). This copy will be removed when the file has been sent to all systems that are connected to this area. CRC check In some *.TIC files the 'Crc' keyword is mentioned, behind which the CRC-32 of the file in question is specified. Using this information FileMgr has a very good way of determining whether was received correctly and completely. FileMgr does this by calculating the CRC-32 of the received file and comparing this value with the CRC-32 which is specified in the *.TIC-file. If these two don't match, the file will be copied to FileMgr's bad file directory (ref. 5.2.4), unless you instructed FileMgr to ignore files with a 'bad crc' (ref. 5.2.6, Ignore bad CRC files). When the latter is the case, the file will remain in the inbound directory. The 'CRC check' statusbit determines whether the check for a valid CRC should be executed. Obviously this check cannot be performed when the received *.TIC files don't contain the 'Crc' keyword. In that case you should ask the SysOp of the system you receive files from to change this for you. Tiny Normally FileMgr adds your network address to the list of 'Path' and 'Seenby' information that it encounters in a received *.TIC file, so the systems that you forward files to can see where the file is coming from and via which route. That's why FileMgr offers you the 'Tiny' statusbit. If this bit is set to 'Yes' FileMgr will only include the information about your own system in outgoing *.TIC files. Use this statusbit 26 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── with extreme caution. Stripping 'Seenby' information increases the chance of duplicates. Remark: I'm aware that this switch (together with the 'MoveToArea' function of the Exception Manager, ref. 5.6) can be used to generate illegal side-branches of closed networks. My position in this is that this is an issue which is the user's responsibility, political and organizational issues are not the responsibility of a programmer. Secure This statusbit determines from which systems you accept files in this area. If the 'Secure' bit is set to 'Yes', FileMgr will only accept files from systems that are listed in the 'Export' list of this area (ref. 'Export'), and of systems listed in the 'Feed(s)' list of the group this area belongs to (ref. 5.3, 'Feed(s)'). If this statusbit is set to 'No' any system can send files to you for this area. For security reasons it is advised to set 'Secure' to 'Yes'. Attention: this statusbit has no effect whatsoever if the 'Closed' statusbit is set to 'Yes' (ref. 'Closed'). Dup check This statusbit determines whether FileMgr, after receiving a file in this area, will check whether this file hasn't been received before by your system. To this end FileMgr uses a list of filenames, file sizes and CRC's that is stored in FileMgr's history file. This check is thorough, and a file with the same name as an already received file is not automatically seen as a duplicate. Both size and CRC must be identical too. This check covers ALL areas, not only the receiving area is checked. If this statusbit is set to 'No', this check will not be performed. The file's information however will always be written to FileMgr's history file. A 'duplicate file' will be moved to FileMgr's bad files directory. Closed This statusbit can be used to further increase the security of certain areas. If this statusbit is set to 'Yes', FileMgr will only accept files in this area from systems that are listed as 'Feed(s)' of the group this area belongs to (ref. 5.3, 'Feed(s)'). The 'Export' list has no influence on this because this statusbit overrules the 'Secure' statusbit. If the 'Closed' statusbit is set to 'No', FileMgr's behavior depends on the setting of the 'Secure' statusbit (ref. 'Secure'). Hide 27 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── If a SysOp requests a list of areas that are available to him from FileMgr, he usually gets a list of all areas belonging to the groups he has access to. In some cases it may be necessary not to show one or more areas in these lists, even though the area is accessible. To accomplish this you can use the 'Hide' statusbit. If you set this statusbit to 'Yes', this area will not appear on any list sent to other systems. Hatch new If you set this Statusbit to 'Yes', FileMgr will check the directory specified in the 'Directory' field for files that weren't there the last time FileMgr looked. If this is the case, and these new files weren't placed there by FileMgr itself, they will automatically be hatched into the area, using the description found in the 'List file'. Subsequently the file will be treated just as if it had just been received by your system, including forwarding and announcing. This is a very handy option for those who regularly download utilities and hatch them in a certain area. This function only works in combination with the commandline option 'NEWSCAN' of FileMgr (ref. 6.8, 'NewScan'). Ann. new This statusbit works similar to the 'Hatch new' statusbit, except that no complete hatch is performed. New files will just be announced by FileMgr as if they had just been received. If you specify the 'Hatch new' switch, setting this switch is unnecessary since 'Hatch new' includes 'Announce new'. Seen-by Here you can tell FileMgr which of your network addresses it should use to update the 'Path' and 'Seenby' keywords in outgoing *.TIC files. When you send files to systems in various networks, it may be easy to select 'AKA matching'. FileMgr will then determine what AKA to use based upon the AKA-matching table (ref. 5.2.2, 'AKA matching'). This depends on the network address of the receiving system. This way you can use your SIGnet address when sending files to SIGnet nodes, and your FidoNet address when sending files to FidoNet nodes. Export This list contains the addresses of all systems you want to forward files to that are received in this area. You can enter the addresses yourself, but systems can also connect themselves to an area provided they have access to the group the area belongs to. If you just receive files from a certain system, and if you never send files to that system, or don't want to send files to this system, you need to specify this system in the 'Feed(s)' list of the group this area belongs to instead of the 'Export' list of the area (ref. 5.3, 'Feed(s)'). 28 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 5.5 Node Manager In the Node Manager you specify the systems you regularly send files to or receive files from. The data in the Node Manager are used to determine which area a certain system has access to, who the files will be sent to, whether the files will be sent crash or put on hold, and which password will be used. Therefore it is very important to enter the data in the Node Manager with great care. These data have a big influence on FileMgr's functionality. System address Here you specify the 4D network address of the system in question. When entering the address you can use the so called short addressing; if you enter just a 1, and your own address is 2:281/ 611, FMSETUP will assume you mean 2:281/1. If you enter .1, FMSETUP will (in this case) change that to 2:281/611.1. Operator name Here you specify the name of the SysOp of the system. This name will a.o. be used in the 'To:' field of NetMail messages. Password Here you specify the password you and the SysOp of this system have agreed upon. Note that the password verification is case- insensitive. For FileMgr the passwords 'FileMgr' and 'FileMgr' are identical. Please choose a fancy password, it reduces the chance someone will succeed at guessing it easily. Available groups Here you specify the groups the system has access to. The SysOp of the system in question can connect to the areas in this group himself provided the 'Remote Maintenance' statusbit is set to 'Yes' (ref. 'Status'). In any case you yourself can connect a system to an area it cannot connect itself to. Visible groups The groups listed here will be in the lists a SysOp can request. Generally you specify the same groups here as in 'Available groups', but it is possible to show areas in lists the system has no access to. These areas will be preceded with a '-' to tell the difference from accessible areas. The SysOp is thus enabled to see what areas your system carries, but can only connect the areas belonging to groups listed as 'Available groups'. Default new group If you allow a system to create new areas on your system, you should specify a group ID here. The newly created area will belong to the area you specify here. All necessary data will be copied from the Group Manager defaults. In order to be allowed to create 29 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── new areas it is necessary that the system has the 'Can create new areas' statusbit set to 'Yes' (ref. 'Status'). *.TIC file type Here you specify what kind of *.TIC files this system wants to receive./ FileMgr can do this in three ways. Your options are: Antique These are normal *.TIC files, which can be processed by programs like Tick. These files have names like TK######.TIC, where the '#' characters represent a unique number. Advanced As far as is known at this time, this type of files can only be processed by FileMgr. They are slightly more compact. Their names look something like FM######.TIC, where the '#' characters represent a unique number. None If you select this option the system concerned will receive no *.TIC files at all. Point systems and other small systems generally do not automatically process files. In that case sending *.TIC files is not useful. If this system has the 'Remote Maintenance' bit set to 'Yes' the SysOp of the system can choose what kind of *.TIC files, if any, he wants to receive. Packing method FileMgr has the ability to bundle the files that are being forwarded to other systems in one big file. This is done using a standard archiving utility, like for instance PKZip (ref. 3.2 and 5.2.5). Here you specify whether any packing should be done, and if so, what files must be packed. None This choice tells FileMgr not to pack any files. All files will be sent separately. Pack *.TIC only Packing of *.TIC files alone doesn't take much HD space, but it will strongly reduce the number of file attaches. This can result in a major speed gain on busy systems. Pack all files This option tells FileMgr to pack all files for this system. You should be aware that this option takes much disk space. Archiver 30 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── When using the pack feature, this is where you decide what archiving utility to use (ref. 5.2.5). Maximum bundle size When using the pack feature, this is where you specify whether FileMgr should try to keep the bundles from getting larger than the amount of kilobytes entered here. This can be helpful prevent many files from getting lost when the bundle gets damaged. Default mail status Here you specify what status the file attaches this system receives will have. You can also specify that on a per group basis (ref. 'Status per group'). Crash Crashmail is usually sent to the receiving system immediately. Hold Mail that is put on hold is usually collected by the receiving system and will not be sent to it. Direct Directmail is usually brought to or collected by the receiving system itself. No intermediate systems will be used for routing the files. For a detailed description of the effect that the various flags have please see your mailer's documentation. Manager mail status Here you specify the status of NetMail messages that FileMgr generates, with the exception of the file attaches. This allows you to have these messages packed or routed. Crash Hold Direct Refer 'Default mail status' For a detailed description of the effect that the various flags have please see your mailer's documentation. Status per group To allow files from some groups to be sent with different settings than specified at 'Default mail status', or use a different packing method than specified at 'Packing method' you can specify whether FileMgr should use the default settings or group specific settings for mail status and/or packing here. 31 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Crash Hold Direct Refer 'Default mail status' Default mail If you select this option the mail status specified at 'Default mail status' will be used. Pack *.TIC files Pack all files Refer 'Packing method' Default packing If you select this option FileMgr will pack the files as specified at 'Packing method'. System status Here you can switch various options on or of for this system. Remote maintenance If this statusbit is set to 'Yes', FileMgr will process messages from this system, thus enabling the SysOp to (dis)connect areas, request lists of available areas a.s.o. himself. Notify This statusbit determines whether or not this system will receive a list of active areas and additional information when you run FileMgr with the 'Notify' commandline parameter (ref. 6.7). Pause If this statusbit is set to 'Yes', this system will no longer receive any files, even when the system is connected to one or more areas. This can be useful when the SysOp is temporarily absent, for instance because of a holiday. If this system has the 'Remote maintenance' statusbit set to 'Yes', the SysOp can switch the 'Pause' bit on or off himself. Pre-release support Not implemented yet. Add to new area This statusbit determines whether this system should be connected to an area that was newly created by another system. Connecting to the area will of course only happen when this 32 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── system has access to the group this new area belongs to (Ref. 'Groups'). Can create new area This statusbit determines whether or not this system is allowed to create new areas on your system. If this statusbit is set to 'Yes' and *.TIC files are received from this system bound for an unknown area, this area will automatically be created. The area will be added to the group mentioned in the 'Default new group' field. Subsequently all systems with access to this group who ALSO have the 'Add to new area' statusbit set to 'Yes' will be connected to this area. 5.6 Exceptions FileMgr offers a set of useful and unique possibilities to give certain files a special treatment. You will find these options in the Exception Manager of FMSETUP. Based on a filemask and an areatag files can be selected and one can determine what should be done with those files. In each of the different exception types a filemask must be specified. Such a filemask may contain standard DOS wildcards. In addition to that you can also use the unique FileMgr wildcards. '#' can be used to replace any numeric digit ('0' through '9'), '@' can be used to replace an alphabetical character ('A' through 'Z'). A number of examples will probably clarify this. Mask Possible matching filenames -------------------------------------------------------- FNEWS???.* FNEWS192.ARC, FNEWS12B.ARC, FNEWS___.ARC FNEWS###.* FNEWS192.ARC NODEDIFF.* NODEDIFF.A92, NODEDIFF.ARC, NODEDIFF.029 NODEDIFF.@## NODEDIFF.A92 -------------------------------------------------------- To avoid unexpected and probably undesired results it is advised to specify the filemasks as accurately as possible. This reduces the chance of selecting wrong files. MoveToArea This is a very useful and powerful option. With this exception you can move certain files from one area to another. This allows you to split or join areas. It also allows you to rename areas. From area This is the tag of the area the move will be performed upon. Files must be received in this area to be processed by this exception. To area 33 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Here you specify the name of the area where the selected files will be moved to. Files will subsequently be processed as if they were received in that area. From node Here you enter the address files moved by this exception will seemingly come from. This to avoid possible security problems. An example to clarify this: Type : MoveToArea File mask : SCAN*.* From area : 4US281 To area : MCAFEE From node : 2:281/603 When your system receives a file that matches the above filemask in the area specified, FileMgr will move this file to the MACAFEE and processed as if it were received from node 2:281/603. AdoptFile This exception was designed to allow processing of files that arrive without an accompanying *.TIC file. You can compare this feature to FileFix. Based on the filemask files are 'adopted' into a certain area. To area Here you specify the area a matching file should be adopted into. From node Here you specify what system FileMgr should consider to be the sender of the file. Description As a *.TIC file is missing, there is no description available. Here you specify the description FileMgr should give this file. In this description you can use FileMgr's template keywords. An example to clarify this: Type : AdoptFile File mask : VSIG####.@@@ To area : TBSCAN From node : 2:281/611.14 Magic : VSIG Description : Latest TBscan(x) signature file @day @dd @month If FileMgr encounters a file in your inbound directory without a *.TIC file that matches the specified filemask, FileMgr will process this file as if it were received in the TBSCAN area from 34 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 2:281/611.14 with 'Latest TBscan(x) signature file' as the description. Furthermore the file will be requestable under the name 'VSIG'. FileMgr checks for the existence of these files AFTER the files that are accompanied by a *.TIC file have been processed. This to prevent the wrong files from being adopted. NoForward Sometimes you may NOT want to forward files from a certain area to the systems that are connected to that area. The 'NoForward' exception can take care of that. From area Here you specify the area concerned. An example to clarify this: Type : NoForward File mask : VSIG####.@@@ From area : TBSCAN In this case the files received in the area TBSCAN that match the filemask VSIG####.@@@ will not be forwarded to the systems connected to this area. The file will however be moved to the BBS directory. PassThru The 'PassThru' exception can be described as the counterpart of the 'NoForward' exception. It allows you to forward files in a certain area without processing them on your BBS. From area Here you specify the area concerned. An example to clarify this: Type : PassThru File mask : VSIG####.@@@ From area : TBSCAN In this case the files that arrive in the TBSCAN area that match the filemask VSIG####.@@@ will not be processed on your system. This means they will not be copied to the directory specified for this area. Files matching the specification will however be forwarded to connected systems. CopyFile 35 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Sometimes moving the file to the BBS directory is not enough. It can be useful to have an extra copy of the file somewhere else on your system. This is where the 'CopyFile' exception comes in. From area Here you specify the area concerned. Directory Here you specify the directory a matching file will be copied to. An example to clarify this: Type : CopyFile File mask : VSIG####.@@@ From area : TBSCAN Directory : C:\VIRUS\DATA\ In this case each file received in the TBSCAN area that matches the filemask VSIG####.@@@ will be copied to the directory C:\VIRUS\DATA. OtherPath Maybe you sometimes receive files in one and the same area that you would like to be in different directories on your BBS. If these files can be recognized by a certain filemask FileMgr can help you here. From area Here you specify the area the files should be selected from. Directory Here you specify the BBS directory the selected file(s) will be moved to. Also the FILES.BBS or it's equivalent will be updated with the name and description of the file in question. An example to clarify this: Type : OtherPath File mask : VSIG####.@@@ From area : TBSCAN Directory : C:\VIRUS\DATA\ If, in this case, you receive a file in the TBSCAN area that matches the filemask VSIG####.@@@, this file will not be placed in the directory specified in the 'Directory' field of that area, but in the directory specified here. That is also where the FILES.BBS will be updated. CopyToArea 36 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── This option enables you to process certain files in various areas. In contradiction to the 'Move'-option, where the file is moved and treated as if it had arrived in a different area, this option also processes the file in the original area. From area Here you mention the area from which the file(s) should be copied. To arrea Here you mention the area the file(s) should be processed in too. The file will be processed both in this area and the originating area. From node Here you enter the address files moved by this exception will seemingly come from. This to avoid possible security problems. An example to clarify this: Type : CopyToArea File mask : SCAN*.* From area : 4US281 To area : MCAFEE From node : 2:281/603 When your system receives a file that matches the above filemask in the area specified, FileMgr will copy this file to the MACAFEE and processed as if it were received from node 2:281/603. The file will also be processed in the 4US281 area. MagicName This option can be very usefull for maintaining the so-called 'magic'-filenames on your system. These 'magic' names are used by your mailer to increase the ease of use of file-requests. A certain program can always be requested under the same name using this method, no matter what the version and/or name of the program. To maintain part of your list of 'magic' names you can use the MagicName option. From Area Here you specify the area the file will be recieved in. MagicName Here you specify the 'magic' name this file should be requestable under. An example to clarify this: Type : MagicName 37 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── File mask : SCAN*.* From area : MACAFEE Magicname : SCAN If a file is received in the MACAFEE area that matches the specified filemask, the 'magic' name list of your mailer will be updated with the magic-name you specify here. In order to have this option function as designed it is necessary that you have your 'Magic name list 1' correctly specified (Ref. 5.2.4) 5.7 Scheduler Some procedures have to be carried out on such a regular basis, it is worth the effort to automize them. To achieve this many utilities are available, but most things can perfectly well be done by FileMgr using the Scheduler. The Scheduler can do many things for you. You can specify whether these tasks should be performed daily, weekly, bi-weekly, monthly or bi- monthly. In contradiction to the exceptions, that are always active if you run FileMgr with the 'Scan' parameter (ref. 6.2) the scheduled events specified here will only be carried out when you run FileMgr with the 'Schedule' parameter (ref. 6.5). It is most useful to do this once a day, for instance during a nightly maintenance event of your system. AutoHatch If a certain file needs to be hatched with a certain frequency, the 'AutoHatch' function can do that for you. This function enables you to hatch a certain file automatically at predetermined times. AKA Here you specify the AKA that should be used when hatching the file. Mask Here you can specify the file that must be hatched. You can specify a complete pathname, but you may also use wildcards (including FileMgr's wildcards '#' and '@'). Tag Here you specify the area the file(s) should be hatched into. Magic If this file should be requestable under a certain 'magic' name, this is where you should specify it. Description 38 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Here you can type a description for the file that will be hatched. You may use all available FileMgr templates for descriptions. An example: Type : AutoHatch Freq : Weekly Fri AKA : 2:281/611 Mask : C:\FILES\FILEMGR\FILEMGR.ARJ TAG : FM_RELEASE Magic : ABOUT Description FileMgr information @day @dd @month This tells filemgr to hatch the specified file every friday in the FM_RELEASE area. The file will be requestable under the name ABOUT and will be hatched from 2:281/611 Netmail If you regularly need to send a NetMail message to someone, send a file or request a file from another system, the 'NetMail' option can be useful to you. This option allows you to send various types of NetMail messages, with or without text in the message itself. AKA Here you specify which of your addresses FileMgr should use for this message. To Here you specify the name of the addressee. Subj Here you specify what should be on the subject line of the message. If you want to send or request a file this is where you enter the filename. Attr Here you select the appropriate attributes for this NetMail message. For a detailed description of the meaning of these attributes please refer to your mailer's documentation. Text Here you can specify the name of a plain ASCII file, which will be imported as the message body by FileMgr. If the message doesn't need to contain any text you can omit this field. An example to clarify this: Type : Netmail 39 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Freq : Weekly Mon AKA : 2:281/611 To : Gerard van der Land, 2:283/15 Subj : GECHO Attr : Crash FilReq Text : Each monday FileMgr will create a crash filerequest for 2:283/15 to request the latest GECHO. No text will be added to the message. *C Report Coordinators like to know what is going on in their net. Usually this concerns information about the areas ant those who are connected to them. Using the '*C report' option you can regularly send a report to those who are interested in one. AKA Here you specify which of your AKA's FileMgr should use for this report. To Here you specify the name and network address of the person you want to send the report to. Attr Select the appropriate attributes for the message. Grps Here you specify which groups should be included in the report. For each group all areas will be listed together wit the connected systems and the average flow per month in that area. An example to clarify this: Type : *C Report Freq : Monthly Day 1 AKA : 2:281/611 To : Ron Huiskes, 2:281/506 Attr : Crash Direct Grps : SPB Every first day of the month FileMgr will create a report of all areas in the groups S, P and B which will be sent to Ron Huiskes at 2:281/506. Exec This option allows you to execute a certain program or batchfile regularly. 40 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Exec Here you specify the full pathname of the program or batchfile you want to execute, including the commandline parameters if any. An example to clarify this: Type : Exec Freq : Monthly Day 1 Exec : \TOOLS\CPT_BAT.EXE 1200 CPT This will make FileMgr execute the program \TOOLS\CPT_BAT.EXE every first day of the month, with '1200 CPT' as commandline parameters. Post This option, together with the 'NetMail' option guarantee FileMgr's reputation as the most complete package. This option allows you to post a message in a certain area on a regular basis. Like anywhere in FileMgr here too you can either directly write the message into the Hudson (QuickBBS) messagebase, of let FileMgr create a *.PKT file that can subsequently be processed by an EchoMail processor. AKA Here you select the address FileMgr should use as the sender of the message. From Here you specify the from name FileMgr should use. To Here you specify who the message should be addressed to. Subj Here you specify the subject of the message. Text Here too you can specify the name of a plain ASCII file that will be imported by FileMgr as the text of the message that should be posted. TAG/board# If you want to use the FileMgr's *.PKT interface this is where you specify the tag of the conference this message should be posted in. If you use a Hudson messagebase, you can specify the area's board number here. 41 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── A typical example of the use of this option is the monthly posting of the area rules in a conference: Type : Post Freq : Monthly Day 1 AKA : 2:281/611 From : Erick van Emmerik To : All Subj : Use of this conference Text : C:\RULES\ECHORULE.012 TAG/Board# : FileMgr_HELP This instructs FileMgr to post the text from C:\RULES\ECHORULE.012 in the FileMgr_HELP conference every first day of the month. 5.8 FileFinder Paragraph 3.4 already discussed the possibility to allow users to look for files on other BBS's through EchoMail using special software like FileMgr or AllFix. By entering a message in an area created especially for this purpose, FileMgr will be triggered on all connecting systems. FileMgr will find out whether the requested files are present on the BBS and, if they were found, will send an answer to the user with information about the files that were found. In FileMgr this feature is called FileFind. Before you can use the FileFind on your system, you need to configure various things. Note that the FileFind feature will only be active when you run FileMgr with the 'FileFind' commandline parameter (ref. 6.6, 'FileFind'). 5.8.1 File areas First you have to tell FileMgr which file areas of your BBS should be checked by FileMgr's FileFind function. To this end FMSETUP reads your BBS'es software. At this time RemoteAccess, QuickBBS and SuperBBS are supported by FileMgr. In the File areas menu you can select all areas that FileMgr should search in. If the file area is selected a small square will appear in front of the name of the area. 5.8.2 Message areas You will also need to tell FileMgr what message areas should be searched for so called FileFind requests. FileMgr allows you to search message areas in two ways. If you use a Hudson (QuickBBS) messagebase FileMgr can directly search your messagebase. If you don't use this type of messagebase, you can let your EchoMail processor export the message areas that must be searched to FileMgr's fake address (ref. 5.2.1). FileMgr will find the ARCmail bundles your EchoMail processor created and unpack them. FileMgr will subsequently search the *.PKT files that emerged from the ARCmail bundle for FileFind requests. 42 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── TAG/board # If you use a Hudson messagebase you can specify the board number of the area that must be searched here. If you want to use the *.PKT interface this is where you enter the tag of the conference that should be searched. Reply board This is where you specify in what area FileMgr should post the replies to FileFind requests. FileMgr has the unique possibility to do this via NetMail (in that case specify 'NETMAIL' or '0' here). Also, like with 'TAG/Board #', you can specify a board number or an areatag here. This does not necessarily need to be the same name or number specified at 'TAG/Board #'. The next few fields determine the layout of the message FileMgr will post as a reply to a successful FileFind request. Here you specify the filenames of so called template files. In these template files you can use all kinds of special keyword that determine the layout of the message. For a detailed description of the template files please refer to paragraph 8.1, Template files. Header Here you specify the name of the template file FileMgr should use to create the header of the message. In this template file you state information about your system like your phone number and the speeds of you modem. Also the header can list what the user originally requested. Footer Here you specify the name of the template file that should be put at the bottom of the message. File entry This template file is used by FileMgr for each file it found and that is included in the message. Name, size and description of the file should not be omitted. Block header This template file is used for each file area FileMgr finds a file in. In this template file you can mention the name of the file area and for instance a line of dashes. Block footer This template file is used at the bottom of each file area that files were found in. Here you can list the total number of files and their total size. 43 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Program ID Here you can choose how FileMgr will identify itself as the program that posted the message. You can chose between a tearline, which is the line at the bottom of a message that starts with '---' followed by the name of the program, or a PID kludge. That is a hidden line that will be entered in the message. Origin line Here you can select the origin line to add to the message. You can also instruct FileMgr to pick an origin line at random (ref. 5.2.7). Origin AKA Here you select the address FileMgr should use as the sender of this message. 5.8.3 Miscellaneous There are a number of other things that influence the behavior of FileMgr's FileFind feature. You find them in this menu. Maximum nr of '?' Here you specify the maximum number of '?' wildcards that may be used in a FileFind request. If a request contains more than that amount FileMgr will refuse to process it. This way you can prevent FileMgr from finding too many files. Expand '*' to '?' FileMgr will accept the '*' wildcard in a FileFind request, but treats it differently than DOS would do. A '*' wildcard in a FileFind request will be translated to the number of '?' wildcards specified here. This too was done to prevent FileMgr from finding too many files. After FileMgr has replaced '*' wildcards with '?' wildcards it checks whether the total number of '?' wildcards doesn't exceed the number specified at 'Maximum nr of '?''. If that is the case, the request will not be processed. Min. keyword length FileMgr's FileFind function can also look for a keyword. In a FileFind request a keyword must be preceded by a '/' character. Here you specify the minimum number of characters a keyword must have before FileMgr will process it. If a keyword is shorter than the number of characters you specify here, the request will not be processed. 44 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Maximum nr of files Here you specify the maximum number of files FileMgr may report found in its reply message to a FileFind request. This field defaults to 30. Entering 0 means there is no limit. Local requests Here you tell the filefind function whether or not it should respond to messages that are found in your own messagebase. 5.9 Message manager In paragraph 5.3, Group manager, the Message Manager was already discussed. The Message Manager contains all information about the announcements that FileMgr will make of received files. Each entry in the Message Manager has it's own unique ID, which is used in the Group Manager to indicate which announcement(s) should be used. In the Message Manager you define where your announcements must be posted, and how they should look. Not that announcements will only be posted when you run FileMgr with the 'Announce' parameter (ref. 6.4, 'Announce). As soon as you receive a file that will be announced FileMgr will show '(announce)' on your screen and in the logfile. This means that data are stored concerning this file so it can be announced. It does NOT mean that the file is announced right that minute. That happens only when you run FileMgr with the 'Announce' parameter. That way it is possible to post your announcements a limited number of times a day, this to avoid too many announcements containing only one file. ID / Descr. Here you specify the ID of the message, and the description of it. The ID is a unique field and will be used to refer to this message. You can chose from characters ranging '0' through '9' and 'A' through 'Z'. This way 36 different announcement messages are possible. The description will be mentioned in the list that is displayed on your screen when you want to select the messages to be used in the Group Manager (ref. 5.3, 'Messages'). An example of a good description is: 'ENET.SOFT, Software announcements Europe' Sort order Here you specify in what order FileMgr should put the files in the announcement. Unsorted FileMgr doesn't sort the filenames. They are listed in order of processing. File FileMgr sorts the filenames alphabetically. 45 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Area FileMgr sorts the filenames by the area they were received in. This also allows FileMgr to place an additional header and footer for each area. Group FileMgr sorts the filenames by the group they were received in. This also allows FileMgr to place an additional header and footer for each group. The next few fields determine the layout of the message FileMgr will post as an announcement. You will need to specify the filenames of so called template files. These template files can contain all kinds of special keyword that determine the layout of the message. For a detailed description of the template files please refer to paragraph 8.1, Template files. Header This template file is placed at the top of each announcement. It should contain information like the name of your system, the date a.s.o. Footer This template file is placed at the bottom of each announcement. It could contain information about the filerequest hours your system has. File entry This template file is used for each file that is being announced. The name, size and description of the file should not be omitted in this template file. Block header This template file will only be used when the sorting method is set to 'Area' or 'Group'. In either of these cases this template file will be used as the header for each area or group that is being announced. The template file could for instance contain the description of the area or the group. Block footer This template file will also be included only when the sorting method is set to 'Area' or 'Group'. This template file will be used as a footer for each area or group. It could contain the total number of files and their total size. TAG/board # When you use a Hudson (QuickBBS) messagebase this is where you specify the board number of the message area the announcement should be posted in. When you use FileMgr's *.PKT interface, 46 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── this is where you specify the area-tag of the area this message should be posted in. If you want to send an announcement to yourself via NetMail you can specify 'NETMAIL' or '0' here. 'From:' Here you specify what should be put in the 'From:' field of the message. You can use your own name, the name of your system, or something completely different. 'To:' Here you specify what should be put in the 'To:' field of the message. 'All' is usually the most appropriate here. 'Subject:' Here you specify what FileMgr should put on the subject-line of a message. Program ID Here you can chose the method FileMgr will use to identify itself as the program that posted this message. You can chose between a tearline, which is the line at the bottom of a message that starts with '---' followed by the name of the program, or a PID kludge, which is a hidden line that is entered into your message. Origin line Here you can select one of your origin lines to use for the message. You can also instruct FileMgr to pick an origin line for the message at random (ref. 5.2.7). Origin AKA Here you select the address FileMgr will use as the sender of the message. Frequency If you don't want your announcements to be posted daily, but only on certain days, this is where you specify that. For each day of the week you can tell FileMgr whether or not it should create this announcement message. This can be used to do certain announcements on one day a week only. 5.10 Import If you have been using Tick, Raid or AllFix before you started using FileMgr, you can use this menu to import data from the configurations of the above mentioned programs into FileMgr's setup. More about this can be found in the paragraphs 4.2 (Tick/Raid) and 4.3 (AllFix). 47 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 5.11 Export You may want to have a short report of some of the data from your configuration in an ASCII text file. You can do this using the Export menu. After choosing one of the options FileMgr will ask you for some additional information when necessary and the name of the text file the report should be exported to. Groups A detailed report of all defined groups. Areas A report of all your groups and the areas that belong to them. For each area the average flow per month will be listed. Member For one system this option lists the tags and descriptions of the areas that system is connected to. Taglist This is a raw list of the tags of all areas in your configuration. Downlinks This is a raw list of the addresses of all systems in your Node Manager. 48 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 6 FileMgr 6.1 General Information FileMgr is the program that does the actual processing of files. You can use the program with a number of commandline parameters. When you start FileMgr without any parameters or with a wrong parameter, the following will appear on your screen: Usage: FileMgr <command> [<command>] Scan Scan, move, forward files. Mgr Process FileMgr requests. Announce Post announcements of arrived files. Schedule Process scheduled events. FileFind Process FileFind requests. Notify [<address>] Send a FileMgr status report to <address>, or to all systems with the 'Notify' flag set. NewScan Scan your areas for new files. Hatch Send files from your system manually. -A<area> Area to hatch file in. -F<filespec> File to hatch. [-X<filename>] File to replace with hatched file. -D<description> Description of hatched file. Use '_' for spaces. [-S] Send file only; don't move to area. [-M<magicname>] Magic request name The operation of the various commandline parameters will be explained in the following items. If you want you can start FileMgr with more than one parameter at a time. The following line for instance, is completely OK: FileMgr MGR SCAN ANNOUNCE FileMgr's commandline parameters are case-insensitive. 6.2 Scan This is FileMgr's base-function. 'Scan' lets FileMgr check the inbound directory for *.TIC files and files that should be adopted. 'Scan' will also keep FileMgr's outbound directory clean. 49 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── If you activate the 'Scan' function and *.TIC files are found, depending on your configuration, something like this will appear on your screen and in your logfile: Scanning inbound path... (1) NODEDIFF.A97 from 2:281/603 in NODEDIFF (move) (announce) (backup) (2) NODEDIFF.A97 to 2:281/611.1 (3) Forwarding to 2:281/611.1 (hold) (direct) (1) (4) Forward: 0 Requests: 0 Files: 1 Bad: 0 Systems: 1 Announce: 0 (5) Active : 0:03 A prompt like (1) will appear as soon as FileMgr notices a *.TIC file in the inbound directory. FileMgr will report the name of the file, the system the file is coming from, the area the file is received in and the various operations FileMgr performs after that. We will discuss a number of prompts from this example: (move) The file is moved to the BBS directory. (announce) An announcement is prepared. Again, this doesn't mean the announcement is posted. In order to achieve that FileMgr must be run with the 'Announce' parameter. (backup) A copy of the file is stored in FileMgr's outbound directory because it needs to be forwarded to one or more systems and because the 'Backup' statusbit is set to 'Yes'. Subsequently FileMgr reports what systems the files that were found must be sent to. In this case (ref. (2)) only 2:281/611.1 will receive this file. As soon as all files have been processed FileMgr will start with the actual forwarding of files. For each system FileMgr will check which files should be forwarded and creates the appropriate file attache(s). In this example you see this on line (3). When all processing is done, FileMgr will report some data about this run (4) and the amount of time it took (5). 6.3 Mgr This is the feature of FileMgr that processes NetMail messages from connected systems. This way the SysOps of these systems can keep an eye on the areas they are connected to. A system can only make use of the 'Mgr' feature when its 'Remote maintenance' statusbit is set to 'Yes' (ref. 5.3, 'Status'). A message to FileMgr must originate from a system mentioned in the Node Manager of your system. The message must be addressed to 'FileMgr' (or one of the names you defined as aliases, ref. 5.2.8, 'Aliases'). The subject line should list the password as specified in the Node Manager for this system. 50 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── The message it self can contain a command to FileMgr on each line. The following commands are available: +<areatag> Connect to a file-echo. -<areatag> Disconnect a file-echo. %+ Connect ALL groups. %- Disconnect ALL groups. %+<grouptag> Connect to a group of file-echoes. %-<grouptag> Disconnect a group of file-echoes. %list Ask for a list of available echo's. %query A list of connected echo's. %unlinked A list of not connected echo's. %tick Send Tick/Raid compatible *.TIC files. %FileMgr Send FileMgr compatible *.TIC files. %none Don't send *.TIC files at all. %pause Put the system temporary on pause. No files will be sent. %resume Start sending files to the system again. %status Ask for a status report (password, pack method). %pwd:<pwd> Change the password to <pwd>. %req:<file> Ask for a specified <file> to be (re)send, with a *.TIC file. %help Ask for instructions (this message) --- Marks the end of your msg (optional) You can determine the layout of the help-message that is sent to as SysOp that sent a '%help' yourself by creating a plain ASCII file called 'FileMgr.HLP' and placing this file in FileMgr's system directory. 6.4 Announce In paragraph 6.2, 'Scan', you read that a received file will not be announced immediately. After reception (if a file must be announced) only the information necessary for the announcement will be written to a file. To actually post the announcements you run FileMgr with the 'Announce' commandline parameter. The file containing the information about received files will be read by FileMgr, and the announcement will be posted. A statement is placed on your screen and in your logfile. An example is found below: Processing message E (sorting) (posting) The message '(sorting)' will only appear if you have set the announcement to sorting on area or group (ref. 5.9, 'Sort order'). Announcements are only processed on the days marked in the Message Manager (ref. 5.9, 'Frequency'). 51 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 6.5 Schedule If you run FileMgr with the commandline parameter 'Schedule', FileMgr will check whether the activities you listed under Scheduler int FMSETUP (ref. 5.7, 'Scheduler') must be executed today. If that is the case FileMgr will display a description of what it is doing both on your screen and in your logfile. FileMgr will execute these activities once a day. If you run FileMgr with the 'Schedule' parameter again straight afterwards, nothing will happen. 6.6 FileFind To activate the FileFind feature of FileMgr you need to run FileMgr with the 'FileFind' commandline parameter. FileMgr will then search the boards and/or *.PKT-files listed by you. On your screen and in your logfile FileMgr will display the following report: Scanning for FileFind requests... Board 66 FileFind request by Erick van Emmerik (searching) (posting reply) Board 65 In this case A FileFind request was found in board 66 of the Hudson messagebase by 'Erick van Emmerik'. FileMgr will subsequently look for the files listed. In this case the search was successful and FileMgr posts a replay message to the request ('(posting reply)'). FileMgr also checks board 65 of the Hudson messagebase, but no FileFind-requests are found. 6.7 Notify If you want to keep the SysOps connected to your system posted of their status on your system, you can run FileMgr with the 'Notify' commandline parameter. There are two ways to use the 'Notify' feature. If you want to send a report to all systems in the Node Manager that have their 'Notify' statusbit set to 'Yes' you can run FileMgr with 'Notify' as commandline parameter. FileMgr NOTIFY If you want to send a report to the SysOp of one specific system, you need to specify that system's address on the commandline: FileMgr 2:281/611.1 You can also use the short addressing method, like in the Node Manager: FileMgr .1 52 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── If FileMgr can find this address in the Node Manager, the report will be sent and FileMgr will report something like this to your screen and in your logfile: Posting statusreport for 2:281/611.1 (query) (help) (list) 6.8 NewScan FileMgr's NewScan feature searches through all areas that have the 'Hatch new' or 'Ann. new' statusbits set to 'Yes' in the Area Manager (ref. 5.4, 'Status'). If a file is found in any of these areas that wasn't there the previous time the 'NewScan' feature was used, this file will automatically be hatched or just announced. Scanning for new files... 26 area(s) scanned, 0 new file(s) found. 6.9 Hatch You can manually send files in an area by 'hatching' the file. The file will subsequently be forwarded to all connected systems, together with an accompanying *.TIC file. FileMgr offers you two ways of hatching. Interactively, so the program can ask you all necessary data, or from the commandline, where you specify all data in commandline parameters. Both methods will be discussed in the following items. 6.9.1 Interactive hatch You activate this method by running FileMgr with 'Hatch' as the commandline parameter. FileMgr will give you a full screen window, where you can enter all required data necessary to correctly hatch a file. Area (TAG) Of course it is necessary to specify the area the file should be hatched in. FileMgr checks the existence of this area in the Area Manager and displays the description. Filename Here you specify the full pathname of the file that should be hatched. FileMgr will check whether the file exists. Replaces If the file you want to hatch is a newer version of an existing file, you can specify the previous version's name here. Other systems can delete the old version subsequently. You should use this option when possible, it saves other SysOps loads of work. 53 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── Magic name If you want the file to be available for FileRequest with a 'magic' filename, this is where you specify the 'magic' name (ref. 5.2.4). Hatch date Not available yet. Release Not available yet. Active AKA Here you select the network address FileMgr should use. FileMgr will default to this address for the 'Seenby'. Generally it is not necessary, and even unwise to change this. Description Here you specify a clear description of the file you are about to hatch. If the file is hatched in an area that will be spread through more than one country, please use the English language. It is very annoying for people abroad to receive descriptions in a language they can not understand. 6.9.2 Commandline hatch The possibility to hatch using commandline parameters is useful when you want to hatch a file from a batchfile. In this case you must make certain all necessary parameters are included. Otherwise FileMgr will not execute the hatch. Commandline parameters that are optional will be marked with block-brackets ('['/']'). All other parameters are obligatory. -A<area> Here you specify the area the file must be hatched in. If FileMgr can not fine the tag in the Area Manager, the hatch will not be executed. -F<filespec> Here you specify the full pathname of the file that must be hatched. If you don't specify a directory, FileMgr will search for the file in the directory belonging to the area. If FileMgr can not find the file, the hatch will not be executed. [-X<filename>] If appropriate, this is where you specify the name of the previous version of the file you are hatching. This filename will be used in combination with the 'Replaces' keyword in the *.TIC files. 54 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── -D<description> Here you specify a clear description of the file you want to hatch. Use the English language when hatching into an international area. You should use '_' to replace spaces in the description. [-S] This parameter makes sure the file is only sent, and it will not be moved to the BBS directory that belongs to this area. [-M<magicname>] Here you can specify a 'magic' name for file requesting this file (ref. 6.9.1, 'Magic name'). 6.10 Using FileMgr's parameters Some of FileMgr's functions you may want to execute as soon as you received one or more files. Other functions should probably be executed once a day only. The best way to start FileMgr after receiving mail/files is: FileMgr MGR SCAN This makes FileMgr process all messages to FileMgr immediately after arrival, and before FileMgr starts processing files. Once a day is enough for the scheduler: FileMgr SCHEDULE Personally I prefer posting announcements, executing filefind and newscan once a day. It strikes me as hardly useful to execute these features each time a mailbundle or other file is received. Of course this is left to your own decision. FileMgr ANNOUNCE FILEFIND NEWSCAN Mind that the NewScan and FileFind features take relatively much time when you execute them each time you receive mail. 55 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 7 HSCAN HSCAN is a simple utility to look in FileMgr's history file. You can use HSCAN with or without a commandline parameter. If you don't specify a parameter HSCAN will give you a list with information about all entries in FileMgr's history file. You can use a filemask containing standard DOS wildcards as a commandline parameter. HSCAN will now give you a list of information about all files that match your specification. This way you can easily check whether or not a certain file was received. 56 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 8 TEMPLATE FILES 8.1 Overview of available keywords in template files. @filename ; full filename 'SAMPLE.ARJ' @fileext ; file extension 'ARJ' @filesize ; file size @filecrc ; file CRC @filedesc ; file description @fileorigin ; file origin address @filefrom ; file from address @filepath ; file path (systems) @fileexport ; number of system file is forwarded to @filerepl ; file which is replaced by the announced file @filemagic ; files 'magic' request name @overflow ; will be replaced by the remainder of a @filedesc or @filepath keyword when it is too long to fit. If there is no remainder, the line on which the @template keyword is used will be omitted completely @areatag ; area tag 'SAMPLE' @areaname ; area name 'Sample file areaname' @grouptag ; group tag 'A' @groupname ; group name 'Another group description' @SysOp ; SysOp full name 'Erick van Emmerik' @SysOpfirst ; SysOp first name 'Erick' @system ; system name 'CrossRoads' @aka ; active system address '2:281/611' @msgto ; message 'to' field 'All users' @msgfirst ; first part of message 'to' field 'All' @quote ; 'quote of the day'. Needs a textfile with quotes (define ; in FMSETUP). @fsearch ; search argument (only valid for FileFind replies) @hour ; hours @min ; minutes @sec ; seconds @dd ; day '10' @d3 ; day 'Thu' @day ; day 'Thursday' @dnr ; daynumber @mm ; month '09' @m3 ; month 'Sep' @month ; month 'September' @yy ; year '92' @y4 ; year '1992' @program ; Current FileMgr program version 'FileMgr GAMMA' @blockcount ; Number of files in the last block @blocksize ; Total size (in bytes) of files in the last block 57 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── @blockkb ; Total size (in Kb) of files in the last block @totalcount ; Number of files in this announcement @totalsize ; Total size (in bytes) of files in this announcement @totalkb ; Total size (in Kb) of files in this announcement 8.2 Overview of available formatting commands. @(<command>[,<command])<keyword> <len> Force lenght to be <length> @(5)program 'FileM' @(15)filename '12345678.123 ' <fr>:<len> Start at pos <fr>, and force length to be <len> @(2:5)program 'ileMg' @(2,15)filename '2345678.123 ' U Force uppercase @(U)program 'FileMgr GAMMA' @(U)filename '12345678.123' L Force lowercase @(L)program 'FileMgr gamma' @(L)program '12345678.123' ~ Just try it (in ENET.SOFT for example :-) @<char> Pad with <char>. Is only valid with <len> or <fr:len> This one defaults to <space> @(@-,15)program 'FileMgr GAMMA--' @(@*,15)filename '12345678.123***' R Right justification. Only useful when used with <len> or <fr>:<len>. @(R,15)program ' FileMgr GAMMA' @(R,15)filename ' 12345678.123' Using the @<char> command @(R,@-,15)program '--FileMgr GAMMA' @(R,@*,15)filename '***12345678.123' 58 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── C Center justification. Only useful when used with <len> or <fr>:<len>. @(C,16)program ' FileMgr BETA ' @(C,16)filename ' 12345678.123 ' Using the @<char> command @(C,@-,16)program '--FileMgr BETA--' @(C,@*,16)filename '**12345678.123**' 8.3 Some examples of the use of keyword and commands. @(R,@0,2)dd-@(R,@0,2)mm-@(2)yy '11-03-92' --@(R,@-,15)areatag---- '---------PDNPASCL----' FileMgr version @(4:4)filename 'FileMgr version 1103' @(@0,R,7)filesize '0126482' @(R,7)filesize ' 126482' 59 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 9 CREDITS 9.1 Copyrights and trademarks All brand and product names are Copyrighted (C) material, Trademarks (tm) or Registered (R) Trademarks of their respective holders: Fido, FidoNet Tom Jennings and Fido Software FrontDoor Joaquim H. Homrighausen AllFix Harald Harms Tick Barry Geller FileMgr, FFD Erick van Emmerik RemoteAccess Andrew Milner & Continental Software, Inc. GEcho Gerard J. van der Land GoldED Odinn H. Sorensen, Goldware International PKZIP PKWARE, Inc. LHA Haruyasu Yoshizaki ARJ Robert K. Jung ARC, ARCmail, SEAdog Systems Enhancements Associates QuickBBS Pegasus Software SuperBBS Risto Virkkala and Aki Antman BinkleyTerm Bit Bucket Software D'Bridge Chris Irwin QEMM, DESQview Quarterdeck Office Systems, Inc. Microsoft, MS-DOS Microsoft Corporation IBM, PC-DOS, OS/2 International Business Machines Corp. 9.2 Thanks, thanks.......THANKS! My profound thanks go to all those who registered FileMgr. Thank you for helping me test, accepting my 'not so well tested' versions, the endless flow of suggestions and ideas. I can't name everyone, but I want to name a number of people, in random order: Charles Gerungan, Ron Huiskes, Henk Heidema, Fabiano Fabris, Paul Boakes, Andreas Klein, Terence Milbourn(e) <ducking>, Marcel 'run-time error [3]' Wouters, Jeroen Smulders, Bo Jakobsen, Bryce Moore, Bob Snowdon, Tobias Burchhardt, Gerard van der land, Joaquim Homrighausen, Jeroen Pluimers, Roelof Heuvel and Donald Heering. My special thanks go to Maurice Snellen for his relentless tries to turn my brewings into acceptable documentation. :-) A big kiss for Tinny, who has had to listen to small-talk an moaning about FileMgr for over a year now and who sometimes has the idea I love my computer more than her. Tinny, a 64k bps connection is nothing compared to what we have together :-) I would sell my HST/DS for you...NOT! 60 FileMgr - the ultimate file processor user guide ───────────────────────────────────────────────────────────────────────────── 9.3 Registration and support For details about registration please refer to the file REGISTER.DOC contained in the FM_*.ARJ files. The following systems offer support and registration for FileMgr: Europe: Erick van Emmerik FidoNet : 2:281/611 Schweitzerplein 57 IntlNet : 57:3101/108 2806 ZS GOUDA SIGnet : 27:1331/716 The Netherlands Data : +31-1820-29508 United Kingdom: Terence Milbourn FidoNet : 2:251/22 97 Sandy Lane Data : +44-425-478436 St. Ives Ringwood HANTS BH24 2LE United Kingdom Germany: Andreas Klein FidoNet : 2:246/47 Werner-Heisenberg-Weg 102 IntlNet : 57:49/0 W-8014 Neubiberg GlobalNet : 52:5202/4 Germany SIGnet : 27:1349/47 Data : +49-89-6017504 Scandinavia: Bo Jakobsen FidoNet : 2:201/138 Gaerdsmygen 1 Data : +46-8-7733240 S-138 00 ALTA, Stockholm North America: Bryce Moore FidoNet : 2:291/22 4141 S Seneca, Apt #1123 Data : +1-316-529-1425 Wichita, Kansas, USA 67217 Australia: Bob Snowdon FidoNet : 3:632/350 17 Witham Drive IntlNet : 58:4100/31 Coldstream, Victoria Data : +61-3-739-0028 Australia 3770 All these systems are capable of modem connections up to v32b. 61