home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
DP Tool Club 8
/
CDASC08.ISO
/
NEWS
/
554
/
MAI
/
NLISTCRC.TXT
< prev
next >
Wrap
Text File
|
1993-10-07
|
2KB
|
34 lines
─ 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.