Ä Fido Pascal Conference ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ PASCAL Ä
Msg  : 246 of 288                                                               
From : Loyd Craft                          1:239/900.0          12 May 93  03:18 
To   : Herb Brown                                                                
Subj : Fido programming..                                                     
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
HB>The nodelist is in one way a little puzzling to me.  What puzzles me is
HB>how the crc is immbeded as text into it.

The CRC that is generated does not include the first line of the Nodelist file, 
where the CRC value is located.   The Nodelist-creating program generates the
entire nodelist, keeps track of the CRC, and then puts in the CRC value at the
top line.

Nodediff applicators have Three means to validate that the diff applys to the
list.

   o  The FIRST method is, the nodediff should have a number 7 larger
      than the Nodelist.  (Remember to allow for the first DIFF of
      January, where the nodelist will have a number GREATER than the
      DIFF, as they use a Julian day number scheme)
   o  The Second method is, the first line of the DIFF holds a copy of
      the First line of the Nodelist file it is to update.  If these two
      lines are not identical, then the diff doesn't apply to the current
      nodelist, and you do not have to go to the trouble of applying the
      diff file.
   o  Lastly, you generate a CRC of the data as you are writing the new
      nodelist, and compare the resulting CRC value to the NEW value provided
      in the Nodediff.  If they match, then everything went fine.
      If they don't, either the nodediff, or the original nodediff are
      tampered with and is likely corrupt.   Usually due to an unknowing
      rookie SYSOP using his favorite text editor to remove the 1+Areacode
      numbers of the local nodes he contacts in my experience.