No doubt you are familiar with Fidonet's life-blood, the message echo which allows you to converse with people from all over the world. Along with the echomail bundles you pick up daily, most likely you have the opportunity to also pick up 'file echos'. This 'cousin' of echomail makes shareware and freeware files from all over the world available daily through the IFDC FileGate Project .This page covers the essentials in file distribution on the bbs side, that is, the sysop who wants to make these files available on his BBS for end users. While it can't possibly replace the documentation for your file tossing software, it may help a bit in understanding the process.
File Echo How-To
There are a number of File Echo Tossing programs such as AllFix. Your BBS system may have its own file tossing software included, or available from your bbs software author separately, or you may be running one of the free-ware tick compatible clones. I'm runningBBBS bbs software, a shareware bbs program, which includes a tick-compatible file manager which is configured pretty easily in bbbs' ASCII text external.bbb file. (darn that's a lot of b's )
Essentially all file tossing software works the same way: You tell the program where on your system you would like to store the files that come in, who will be sending the files to your system and to whom they should be sent once received, whether to make the files passthrough or not, and most likely, the bbs's name for the file area.
Barry Geller included a neat function in the original TICK. By putting two flags together, asterisk (*) and ampersand (&), you could indicate in your configuration file that files in a particular area were "receive only", such as receive from an uplink so that you can send them to your downlinks. While allfix and filemanager do not use such notation, they do use the English language equivalent with words like, "receive-from only", "send-only", and "Send & Receive", etc.
Backchannel areas are areas that allow a sysop to send files upstream to a file distribution HQ's site. Backchannel areas also use this type notation (*&) in the FileGate.zxx file. Theoretically, if you release a file in a backchannel area, and your uplink is major HUB, your file will be forwarded on to the FDN Coordinator's system. The PDN has such an area, PDNHATCH. The WIN-FDN also uses backchannel areas, WIN_2HQ. See the Filegate.zxx for other FDNs who use these type areas.
Files hatched in these areas on your system will first go to your uplink, and if your uplink is a HUB, it will continue up the chain to the HQ of the respective FDN, where it can be examined, checked for viruses and then released by the coordinator into the file stream. If your uplink is not a major HUB, the file you hatch may 'dead-end' as it's called, or stop somewhere up the line since no one is required to pass these files along.
You can also have Tick and tick compatible programs calculate the CRC values of every file which comes into your system. This is actually pretty important. The CRC of a file, or Cyclic Redundancy Check, allows software like tick, etc., to check whether a file has been damaged or changed since it was hatched. The CRC of a file is a unique signature and the value of the CRC is put in the .tic file so that the file processing program can read what it should be, or rather what it was when the file was originally hatched. When a file's CRC fails to match the CRC value that is reported in the .tic file, the .tic file will be named *.bad and that file and it's tic will not distributed further.
TopThe CRC value can change if a file is commented after hatching, or if the entire archive (zip or whatever) did not arrive, causing a CRC failure. Coordinators know that they must always comment the files first, and then hatch them. Speaking of commenting files, the FileGate, and many of the participating FDNs, have policies in place that ask that you do not change a files' comment until all of your downlinks have received the original file. Most of these features in TICK are set in the tick.cfgfile above the file description areas.
TICK File Echo Manager:
Tick uses a simple ASCII configuration file (see tic.cfg )which lists your zone-net-node info, work directory, etc. and a list of the area segments which indicates the areas you want to import. Each segment represents a file echo, and that segment lists the nodes who will be sending that file echo to you, or picking up that file echo from you, and where you keep the files on your drives:
TopWhen tick is run in the mailer's batch file, it reads the .tic files in the incoming directory, moves the archives associated with the tic to the directory specified in your config file, updates the directory's file description (files.bbs type) file, generates new .tic files and file attach messages for your downlinks. Tick was great because I don't think I've seen a bbs software package that couldn't use it - perhaps not easily, but it could be done=====example tic.cfg file for fictitious node 1:2320/17 =====
ZONE 1 c:\tick\outbound
ListFmt %3:-13 %1
Area c:\files\pdn\pdnhatch PDNHATCH
1:2320/38 PASSWORD C
2:2/24 PASSWORD &*
3:1/21 PASSWORD &*
;; 1:2320/38 has files crashed to it
;; Other sites are set "receive -from only" , and those files will then be crashed to 1:2320/38
Area c:\files\pdn\PDNCEE PDNCEE
1:2320/38 PASSWORD *&
1:720/11 PASSWORD C
2:2/24 PASSWORD C
;;1:2320/38 is receive -from only
;;Other nodes have files crashed to them
==end of tic.cfg===
BBBS Built-in File Echo Manager:
The shareware bbs program, BBBS, uses the following format for file echos in the file, external.bbb , on my linux box:
; gr tag path aka(s) afl export /description
; -- ---------------------- ----------------------------------- --------------- ------ --------------------------------------------- -------------------------------------------------
F NODEDIFF /bbbs/files/nodediff/ 1:2320/38 VA 1:103/105 109/921 2:270/312 3:775/715 /Fidonet Nodelist Difference File
The F in the first column is a group designator which you can tie to permissions for access to the file echo in the [nodes] section.
VA says to make the area visible (V) and to create an ASCII text file regarding the release so that you can announce the file (A).
TopNode information regarding crash, hold, etc. is contained in the [nodes] section of the external.bbb file, though you can include it on this line if you like, i.e.,
Send this file to this node with Hold flavor for pickup
The above line will Import from 1:2320/38, and export to 1:140/1.
ALLFIX File Manager
Allfix file echo processor, is stand-alone shareware program and can be used with most BBS Systems. AllFixuses a config program (ASETUP) that you run to make changes to the config file. ASETUP's interface is much like the FrontDoor mailer's config program - the set up cannot be done in an ASCII config file.
The ASETUP main screen leads you to different manager menus for different parts of the program, such as node manager, file echo manager, and group manager, etc. In each of these managers, you enter information for that manager.
In Node manager, you enter the node numbers, passwords and mail flavor of those who will be calling your system.
The File Echo Manager allows you to view or change the actual tag names, add description of the tags and indicate where the files are to be stored.
If you want to use them, the Groups manager will allow you to remove or change similar file echos, or groups of echos.
Allfix saves all the information in a database. One thing you might want to do often is backup your allfix directory... after entering all of that information, you sure wouldn't want to lose it and have to re-enter it .
Back to Zone 1 Home Page