Synchronet v3.19b-Win32 (install) has been released (Jan-2022).

You can donate to the Synchronet project using PayPal.

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
ref:fidonet_files [2010/02/25 14:46] – digitalmanref:fidonet_files [2020/12/24 17:23] (current) – [Stored Message] typo digital man
Line 1: Line 1:
 ====== FidoNet Files ====== ====== FidoNet Files ======
-This page contains details regarding files, their names and contents, used FidoNet networking.+This page contains details regarding the names and contents of files used in FidoNet networking (netmail and echomail).
  
 ===== Background ===== ===== Background =====
Line 48: Line 48:
 attachments, but do **not** support Stored Messages. Binkley/FLO attachments, but do **not** support Stored Messages. Binkley/FLO
 style mailers always send NetMail messages packed into Packets, style mailers always send NetMail messages packed into Packets,
-so there is no "netmail" sub-directory of folder normally+so there is no "netmail" sub-directory or folder normally
 associated with a Binkley/FLO-style mailer and they don't associated with a Binkley/FLO-style mailer and they don't
 deal with Stored Messages (a.k.a. ".msg files"). deal with Stored Messages (a.k.a. ".msg files").
Line 58: Line 58:
 one or more Packed Messages. one or more Packed Messages.
  
-Packets may contain NetMail or EchoMail messages.+[[ref:FidoNet Packets]] may contain NetMail or EchoMail messages.
  
-Packet files have a ''.pkt'' suffix (SBBSecho names Packet+Packet files have a ''.pkt'' suffix (SBBSecho v2 named Packet
 files "in process" with a ''.pk_'' suffix). The base file name files "in process" with a ''.pk_'' suffix). The base file name
 of a Packet can actually be *anything*, but is usually a of a Packet can actually be *anything*, but is usually a
-numeric time stamp of some sort. SBBSecho uses "DDHHMMSS" +numeric time stamp of some sort. SBBSecho v2 used "DDHHMMSS" 
-(where each pair of letters is a 2-digit zero-padded decimal +where each pair of letters is a 2-digit zero-padded decimal 
-number representing the Day of the month, hour of the day, +number representing the day of the month, hour of the day, 
-minute, and second at the time the packet was created)+minute, and second at the time the packet was created while 
 +SBBSecho v3 uses the packet creation time in Unix time_t format 
 +(seconds since Jan-1-1970) represented with hexadecimal digits
 as the base file name when creating Packet files. The as the base file name when creating Packet files. The
 important thing is that the Packet files have unique names. important thing is that the Packet files have unique names.
Line 162: Line 164:
  
 Flow Files are unique to Binkley/FLO-style (a.k.a. Binkley-Style-Outbound, or Flow Files are unique to Binkley/FLO-style (a.k.a. Binkley-Style-Outbound, or
-BSO) mailers  and are not an FTN standard. Flow Files are control files+BSO) mailers  and are defined in [[http://ftsc.org/docs/fts-5005.002|FTS-5005]]. Flow Files are control files
 containing plain text (so they can be easily viewed or edited, unlike the containing plain text (so they can be easily viewed or edited, unlike the
 other file types described in this document). other file types described in this document).
Line 170: Line 172:
   NNNNnnnn.Flo   NNNNnnnn.Flo
  
-where "NNNN" is the destination node number as a 4-digit zero-padded +where "NNNN" is the destination network number as a 4-digit zero-padded 
-hexadecimal number, and "nnnn" is the destation network number as+hexadecimal number, and "nnnn" is the destination node number as
 a 4-digit zero-padded hexadecimal number, and "F" indicates the a 4-digit zero-padded hexadecimal number, and "F" indicates the
 "Status" of the Bundles or Packets listed in this file: "Status" of the Bundles or Packets listed in this file:
-(C)rash, (D)irect/Immediate, (H)old, or F, for "Normal".+(C)rash, (D)irect/(I)mmediate, (H)old, or F, for "Normal".
  
-Another permuation of this scheme is used when the destination +Another permutation of this scheme is used when the destination 
 address is a "point" address. In this scheme, the base file name address is a "point" address. In this scheme, the base file name
 is the destination point number as an 8-digit zero-padded hexadecimal is the destination point number as an 8-digit zero-padded hexadecimal
Line 184: Line 186:
   NNNNnnnn.pnt   NNNNnnnn.pnt
  
-where "NNNN" is the destination node number as a 4-digit zero-padded +where "NNNN" is the destination network number as a 4-digit zero-padded 
-hexadecimal number, and "nnnn" is the destation network number. So,+hexadecimal number, and "nnnn" is the destination node number. So,
 for example: for example:
  
Line 205: Line 207:
 indicates whether or not to delete or truncate the file after its indicates whether or not to delete or truncate the file after its
 been sent (i.e. '#' indicates truncate, '^' indicates delete). been sent (i.e. '#' indicates truncate, '^' indicates delete).
 +==== BT-USER.TXT ====
  
-More on this from the BinkleyTerm v2.60 User Guide (BT-USER.TXT):+Snippet explaining "Flow Files" from the BinkleyTerm v2.60 User Guide (''BT-USER.TXT''):
  
-===== BT-USER.TXT ===== +=== Idea #4 ===
- +
-==== Idea #4 ====+
 Use File names to control traffic Use File names to control traffic
 The driving forces of outbound traffic are file names! The driving forces of outbound traffic are file names!
Line 347: Line 348:
 For more information on how oMMM or your processor/packer works, For more information on how oMMM or your processor/packer works,
 refer to its specific documentation. refer to its specific documentation.
- 
-... and from the BinkleyTerm 2.60 Reference Manual (BT-REF.TXT): 
  
 ===== BT-REF.TXT ===== ===== BT-REF.TXT =====
  
-Where is the outbound area for points?  Let's say you are storing+Snippets from the BinkleyTerm 2.60 Reference Manual (''BT-REF.TXT'') explaining outgoing file requests and Binkley/FLO style outbound directories for point nodes. 
 + 
 +==== Outgoing file requests ==== 
 +These can be generated by BinkleyTerm or by using one of the many 
 +utilities designed for the purpose, such as Amax, Bonk,  Please, 
 +etc.  Any Opus-compatible file request builder can be used with 
 +BinkleyTerm.  You may also manually build file requests.  They are 
 +a single-line flat ASCII text file, and are named in the same 
 +manner as packets (refer to the User Manual section "How 
 +BinkleyTerm Handles Mail" for information on the naming convention) 
 +and have a file extension of .REQ.  Outgoing requests should NEVER 
 +have a drive and path designation; only the file name.  The remote 
 +system handles the drives and paths. 
 + 
 +The ''.REQ'' file is placed in your outbound holding area. 
 + 
 +BinkleyTerm will not place calls for a stand-alone .REQ file.  In 
 +order for a call to be placed, a packet or file attach of the 
 +proper flavor must also exist (this will be prepared, along with 
 +the .REQ file, by utilities such as Bonk and Amax).  You can also 
 +manually poll to send the request immediately. 
 + 
 +==== Points ==== 
 + 
 +Where is the outbound area for points? Let's say you are storing
 mail for points off of a system whose address is 1:132/491.  You mail for points off of a system whose address is 1:132/491.  You
 would do so by creating a directory ''008401EB.PNT'' in your Zone 1 would do so by creating a directory ''008401EB.PNT'' in your Zone 1
Line 363: Line 386:
  
   C:\BINKLEY\OUTBOUND\008401EB.PNT\0000000C.CUT   C:\BINKLEY\OUTBOUND\008401EB.PNT\0000000C.CUT
 + 
  
 ===== See Also ===== ===== See Also =====
 +  * [[:howto:fidonet|How-To Join FidoNet]]
 +  * [[:util:SCFG]]
 +  * [[:network:FidoNet]]
   * [[:ref:|Reference Library]]   * [[:ref:|Reference Library]]
  
 {{tag>fidonet}} {{tag>fidonet}}
  

Trace: