Subj : FidoNews 32:13 [03/08]: Ftsc Information To : All From : FidoNews Robot Date : Mon Mar 30 2015 00:35:44 ------------------------------------------------------------------- |12|13|14|15|16|17|18|19|20|21|22|23|00|01|02|03|04|05|06|07|08|09| ------------------------------------------------------------------- i |xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx| c |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--| d |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--| f |--|--|--|--|--|--|--|--|--|xx|xx|xx|xx|xx|xx|xx|xx|xx|xx|--|--|--| h |--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--|--| ------------------------------------------------------------------- 3.4. Differences in flow and reduced flow files. "Real" flow file means that the system has a portion of information to be sent while a reduced flow file only expresses a desire to make a poll. Thus if a mailer detects a flow file in the directory, it must determine whether this is a real flow file or just a control file. If it is a real flow file the mailer must make a poll accor- ding to the flavour, send information to the remote according to the type of flow file and delete the flow file after sending all information. The mailer should not wait for the end of the session when deleting the flow file. Thus if a session is terminated accidentally or deliberately after sending the flow file information the mailer will return to its previous state without a priority flow file in the outbound. If it is a reduced flow file the mailer must make a poll according its flavour. The mailer has nothing to send from the control file and it must delete the flow file after the successful end of session. Thus if a session is terminated accidentally or deliberately while sending information, the mailer will return to its previous state with the priority flow file in the outbound. That is why it is not a good idea to lock flow files during the session. 4. File Requests ---------------- 4.1 File request files are named using the same method as flow files, with an extension of req. The format of request files is documented in FTS-0006. File requests have no flavour on their own. They DO NOT initiate a poll to the remote system, and must be accompanied by a [reduced] flow file. File requests may have additional restrictions (for example, based on Nodelist flags or ZMH restrictions) specific to the request. Normally this file is deleted after receiving the requested files. As with NetMail flow files, during a session this file must be dynamically renamed at the moment of sending to a remote system with a unique name and extension of req. 5. Control files ---------------- 5.1. bsy (busy) control file A bsy is a main control file that must be used by any software dealing with flow files in BSO. It is named the same way as the flow file but with the extension ".bsy". Any software must check this file before doing any changes in flow files. If a bsy file exists all changes are prohibited in any corresponding flow files. What the software must do in this case is implementation dependent. If a bsy file does not exist software must create it, ensure that it was successfully created, and then work with the flow files. After completing the job, software must delete the bsy file. Note to software developers: The most common way to create a file in many languages (eg. ReWrite, fopen) also quietly overwrites an existing file, so there's a race condition between checking, creating and checking. Care must be taken to use the right function and/or the right options to get the correct behaviour. During the session and before sending information from flow files the mailer creates the list of all AKAs presented by the remote system. The mailer must then check bsy files corresponding to the list. If a bsy file is detected the corresponding AKA is removed from the list. If all AKAs are removed due to this procedure, the session must be terminated with an appropriate diagnostic message. If a bsy file for the AKA is not present the mailer must create it. A bsy file is created by the mailer only after a successful connection with the remote mailer. After session - successful or not - the mailer must delete all created bsy files. After restoring the system due to a crash it is recommended to run a simple routine to delete all bsy files in all outbounds before starting any software dealing with BSO. It is also recommended to check the age of bsy files. It is reasonable to ignore and delete bsy files with an age more than the maximum estimated time of session multiplied on 2. An appropriate diagnostic message may be produced in this case. For information purposes a bsy file may contain one line of PID information (less than 70 characters). 5.2. csy (call) control file This control file is created by a mailer when it decides to make poll to remote system. It is named the same way as a flow file but with the extension ".csy". A csy file is valid only for another mailer working together on the same system. Note that the remark regarding race conditions when creating a bsy file, also applies when creating a csy file. csy files are created for all remote AKAs as shown in the mailer config. The presence of a csy file corresponding to any remote AKA indicates that the mailer must stop trying to poll the remote system regardless of the presence of flow files. After a session - successful or not - and after an unsuccess- ful try the mailer must delete all created csy files. After restoring a system due to a crash it is recommended to run a simple routine to delete all csy files in all outbounds before starting any software dealing with BSO. It is also recommended to check the age of csy files. It is reasonable to ignore and delete csy files with an age more than the maximum estimated time of a session multiplied by 2. An appropriate diagnostic message may be produced in this case. For information purposes, a csy file may contain one line of PID information (less than 70 characters). 5.3. hld (hold) control file This control file is created by a mailer or other software when it decides to stop trying poll a remote system. hld file is meaningful only for mailers. It is named the same way as a flow file but with the extension ".hld". An existing hld file is either replaced by a new one or edited. A hld file must contain a one line string with the expiration of the hold period expressed in UNIX-time. The presence an hld file corresponding to any remote AKA indicates that the mailer must check the content before trying to poll the remote system. If the expiration time is in the future, the mailer must stop trying to poll the remote system regardless of the presence of any flow files. The presence and content of an hld file must be checked before each attempt to create a poll. If software finds an hld file with an expiration time in past, it must delete that hld file. For information purposes the second line of an hld file may contain one line of PID information. (Less than 70 characters) 5.3. try control file This control file is created by a mailer when a connect attempt is finished - successful or not. It is named the same way as a flow file but with the extension ".try". An existing try file is replaced by a new one. A try file must contain one line string with a diagnostic message. It is for information purposes only. For information purposes the second line of a try file may contain one line of PID information. ( < 70 characters) A. References ------------- [FTS-0001] A Basic FidoNet(r) Technical Standard Randy Bush, 30 Sep 95. [FTS-0006] YOOHOO and YOOHOO/2U2 Vince Perriello, 30 Nov 1991. T-Mail. Reference Manual Andy Elkin, 1997. BinkleyTerm. Reference Manual 1987-1996 Bit Bucket Software, Co. B. Contact Data --------------- Igor Romanovsky Fidonet: 2:5022/60 E-mail: Igor.Romanovsky@tula.net Administrator Fidonet: 2:2/20 E-mail: administrator@ftsc.org C. History ---------- This document is based on FSP-1034 by Igor Romanovsky. Some minor technical modifications were made by Markus Reschke, Fred Riccio and other FTSC members. Grammar and typographical corrections were made by Dallas Hinton and others. Rev.1, 2014-11-09: Initial Release. Rev.2, 2015-03-29: Added section on file requests, fixed typos. Minor reformatting. ----------------------------------------------------------------- --- Azure/NewsPrep 3.0 * Origin: Home of the Fidonews (2:2/2.0) .