Does anyone know of a utility to get the CRC of a file? A node is
creating tic files by hand, or a script I guess and we need the CRC
value of the file to put in the tic.
http://cmech.dynip.com/filebase.bbs/bfds/horst32.zip
See crc32 pgm within (DOS/Wins) ... also see CRC32.TXT
Alan Ianson wrote to All <=-
Does anyone know of a utility to get the CRC of a file? A node is
creating tic files by hand, or a script I guess and we need the CRC
value of the file to put in the tic.
Also, does anyone know of a file that documents the keywords available
for tic files and their meaning?
... After all is said and done, much is said and little is done.
Also, does anyone know of a file that documents the keywords
available for tic files and their meaning?
I did find those a while back. Don't have specific links, but Google will fish them out. They weren't of use to me then, as I didn't have the contextual understanding to make use of them when I looked. Probably more useful now that I understand the key fields. I'm about to head out to a track meet, otherwise I'd google them for you (since I want them myself).
Ben Ritchey wrote to Alan Ianson <=-
http://cmech.dynip.com/filebase.bbs/bfds/horst32.zip
See crc32 pgm within (DOS/Wins) ... also see CRC32.TXT
http://cmech.dynip.com/filebase.bbs/bfds/horst32.zipOnly problem is they're DOS programs. Not the easiest to run from a script under Raspian. Pity the source isn't available. :(
See crc32 pgm within (DOS/Wins) ... also see CRC32.TXT
http://cmech.dynip.com/filebase.bbs/bfds/horst32.zip
See crc32 pgm within (DOS/Wins) ... also see CRC32.TXT
Only problem is they're DOS programs. Not the easiest to run from a script under Raspian. Pity the source isn't available. :(
Does anyone know of a utility to get the CRC of a file?
A node is creating tic files by hand, or a script I guess and we need
the CRC value of the file to put in the tic.
Also, does anyone know of a file that documents the keywords available
for tic files and their meaning?
Does anyone know of a utility to get the CRC of a file? A node is
creating tic files by hand, or a script I guess and we need the CRC
value of the file to put in the tic.
Seems Mystic doesn't require the CRC. I'm able to hatch files without it.
http://cmech.dynip.com/filebase.bbs/bfds/horst32.zip
See crc32 pgm within (DOS/Wins) ... also see CRC32.TXT
Only problem is they're DOS programs. Not the easiest to run from a script under Raspian. Pity the source isn't available. :(
Does anyone know of a utility to get the CRC of a file?
there are several... you always forget to tell what OS you need things for...
A node is creating tic files by hand, or a script I guess and we
need the CRC value of the file to put in the tic.
why don't they use what is already available?
Also, does anyone know of a file that documents the keywords
available for tic files and their meaning?
http://ftsc.org/
Janis Kracht wrote to Tony Langdon <=-
I have some source for CRC here:
http://www.filegate.net/cprog/pdcrc200.zip
Ben Ritchey wrote to Tony Langdon <=-
See Tuxpower echo, solution available there :)
mark lewis wrote to Tony Langdon <=-
there shouldn't really be any TIC software that /requires/ the CRC...
it's only
real use is to ensure that the file is not changed in transit...
depending on your OS, you may have the necessary tools already at
hand...
cksum
crc32
cksum or crc32 is the one you want but you should check with a known
file that has a known CRC value and see which program outputs the same match... i say this because at least crc32 hashes can have pre- and
post- conditioning applied
to them...
i had to initialize the crc variable to $ffffffff (as a signed
longint) and then feed each character individually to the crc
routine... i could have fed the entire blob of data and let the routine walk through it but that gave a different and wrong result... at the
end, we did not XOR with $ffffffff but we do have to invert the result
so the bytes are reversed since to match what's in
the JAM data files... this byte reversal is because the legacy method used is for traditional analogue modems and the UART wants everything reversed for transmission... granted a UART is not used in this case
but it is the way the sofware is written and there's a lot of software that uses this same formulation method...
[time passes]
i just checked what i was checking for JAM with the cksum and crc32
tools but neither returned the desired results... i'll have to go play, now, with checking a file and its TIC to see if i can determine which
is correct if either one is... pre- and post- conditioning and whether
to flip the bytes or not make a huge difference in the results...
mark lewis wrote to Tony Langdon <=-
the ones i listed are all pretty standard on *nix... the problem is if they are
using the same formula or not...
Alan Ianson wrote to mark lewis <=-
I think Tony has done this now with a script although we need to add a valid Crc line to the tic. Mystic itself will toss tics without a crc
line but I think a validity check is good to have.
Sysop: | digital man |
---|---|
Location: | Riverside County, California |
Users: | 1,054 |
Nodes: | 15 (0 / 15) |
Uptime: | 54:33:50 |
Calls: | 500,777 |
Calls today: | 9 |
Files: | 109,358 |
D/L today: |
51,290 files (8,315M bytes) |
Messages: | 466,002 |
Posted today: | 3 |