The MacBinary II+ problem

From MacBinary II Conference 6/21/87:
To determine if a header is a valid  MacBinary header, check bytes 0 and 74 to
be both zero.  If they are both zero, either (a) the CRC should match, which
means it is a MB II file, or (b) byte 82 is zero, which means it may be a MB I
file.  (Note that, at the current version level, byte 82 is kept zero to
maintain compatibility with MacBinary I. If at some point the MacBinary
versions change sufficiently that it is necessary to keep MacBinary I programs
from downloading these files, we can change byte 82 to non-zero.)

OK, very nice, but... what when all the bytes are 0x00 ????
The CRC gives 0 too, so this method would return "valid MB II file" !

This is why MacGzip 1.0, when the "decode MacBinary" preference is enabled, fails to expand files whose original contens was all zeroes.
In version 1.1, I check the "name lenght" field; and if it is zero, it is not a valid MB file. (This will make the CRC check enough for the rest of the cases)(I guess...)