Forum unknown
· Telecommunications
AmigaBinary
9 messages in this thread
Maybe I'm missing something but I don't understand want the CRC adds. The
header block will be verified by the protocal used, thus no internal CRC is
needed. The intent when using MacBinary is that all files are either MacBinary
or Text. This assumption fails if you are attempting to move a non-Mac binary
file (which I would consider to be an "expert" requirement). In that case,
terminal programs should allow the user to turn off MacBinary translation.
I agree about date stamping and would like to have it included. I just
currently see no way to "set" the date of a file. Maybe someone who knows more
about AmigaDos can reveal how to do this. It would make sense to allocate 12
bytes starting at offset 91 to correspond to the AmigaDos structure DateStamp.
Am I missing anything else? Bill Bond
The CRC is an extra assurance for a number of reasons. While it is more than
likely that the header could be detected by analyzing its format, it is
possible that random data could be mistaken for a header. Red Ryder and
MicroPhone, for example, require the user to turn the MacBinary detection on
and off for binary files – this is very user-unfriendly, especially for novices
who know just enough to log onto a service like this, let alone understand all
of the intricacies of protocols and file formats.
This way, you can do a cursory check to assure that bytes 74 and 82 are 0, and
if they are, double check the header with the CRC value. If everything is in
line, then you continue via the format's specs. If not, you just do a dumb
transfer with no formatting.
MacBinary (and ABTF) specify 8 bytes for time/date, not 12, but yes, I think
space should be reserved for it right now to save confusion later.
[ Russ ]
The CRC is an extra assurance for a number of reasons. While it is more than
likely that the header could be detected by analyzing its format, it is
possible that random data could be mistaken for a header. Red Ryder and
MicroPhone, for example, require the user to turn the MacBinary detection on
and off for binary files – this is very user-unfriendly, especially for novices
who know just enough to log onto a service like this, let alone understand all
of the intricacies of protocols and file formats.
This way, you can do a cursory check to assure that bytes 74 and 82 are 0, and
if they are, double check the header with the CRC value. If everything is in
line, then you continue via the format's specs. If not, you just do a dumb
transfer with no formatting.
MacBinary (and ABTF) specify 8 bytes for time/date, not 12, but yes, I think
space should be reserved for it right now to save confusion later.
[ Russ ]
The CRC is an extra assurance for a number of reasons. While it is more than
likely that the header could be detected by analyzing its format, it is
possible that random data could be mistaken for a header. Red Ryder and
MicroPhone, for example, require the user to turn the MacBinary detection on
and off for binary files – this is very user-unfriendly, especially for novices
who know just enough to log onto a service like this, let alone understand all
of the intricacies of protocols and file formats.
This way, you can do a cursory check to assure that bytes 74 and 82 are 0, and
if they are, double check the header with the CRC value. If everything is in
line, then you continue via the format's specs. If not, you just do a dumb
transfer with no formatting.
MacBinary (and ABTF) specify 8 bytes for time/date, not 12, but yes, I think
space should be reserved for it right now to save confusion later.
The CRC is an extra assurance for a number of reasons. While it is more than
likely that the header could be detected by analyzing its format, it is
possible that random data could be mistaken for a header. Red Ryder and
MicroPhone, for example, require the user to turn the MacBinary detection on
and off for binary files – this is very user-unfriendly, especially for novices
who know just enough to log onto a service like this, let alone understand all
of the intricacies of protocols and file formats.
This way, you can do a cursory check to assure that bytes 74 and 82 are 0, and
if they are, double check the header with the CRC value. If everything is in
line, then you continue via the format's specs. If not, you just do a dumb
transfer with no formatting.
MacBinary (and ABTF) specify 8 bytes for time/date, not 12, but yes, I think
space should be reserved for it right now to save confusion later.
Oh yes, forgot to respond to the "expert" requirement. Whether or not it is,
it costs no more to put the CRC in for integrity just to be sure, ne-c'est pas?
I don't see where it needs to be mandated that a file _must_ always be sent
formatted (or be text) – that seems like a self-imposed limitation which can be
avoided.
[ Russ ]
Oh yes, forgot to respond to the "expert" requirement. Whether or not it is,
it costs no more to put the CRC in for integrity just to be sure, ne-c'est pas?
I don't see where it needs to be mandated that a file _must_ always be sent
formatted (or be text) – that seems like a self-imposed limitation which can be
avoided.
[ Russ ]
Oh yes, forgot to respond to the "expert" requirement. Whether or not it is,
it costs no more to put the CRC in for integrity just to be sure, ne-c'est
pas? I don't see where it needs to be mandated that a file _must_ always be
sent formatted (or be text) – that seems like a self-imposed limitation which
can be avoided. [ Russ ]
Oh yes, forgot to respond to the "expert" requirement. Whether or not it is,
it costs no more to put the CRC in for integrity just to be sure, ne-c'est
pas? I don't see where it needs to be mandated that a file _must_ always be
sent formatted (or be text) – that seems like a self-imposed limitation which
can be avoided. [ Russ ]