Well, first we cannot and should not develop the most universal programm that cann handle any data formats. Nope. I'm just handling what they actually bothered to document.
Let's assume I let the user work with the false format. Your programm can destroy the file, which was propably your file with whole your passwords, which you forget to make write-protected.... Well if the user is stupid enough, there's not much we can do to save him.

He can destroy a file with notepad or vi after all. Using my program though, he's first have to ignore the warning about a probable invalid file format, then he's have to search and display at least one record, which will appear as gibberish. Then he'd have to ignore the fact it's gibberish and try to book the record anyway (which will only work if the customerID field happens to be blank). At that point, if the user discovers he's destroyed his password file, he doesn't really deserve any sympathy, IMO.
My point is : The programm should accept only that format what it can interpret. I would agree if I knew for sure whether the program could interpret a given file. I don't think we really know this though, so I try to be flexible.
As a similar example - hava you ever used JAD, the
Java decompiler? Very cool program. Unfortunately it hasn't been updated in some time, and it doesn't understand some details of the JDK 1.4 class structure. When you run it, it checks a file format version number at the beginning of each class file to see if it falls within the range of versions it's designed to handle. Which basically extends up through JDK 1.3. Now, I've had files that were generated by JDK 1.4 which I wanted to decompile. I suspected that even though they used 1.4, they probably didn't actually use the new features of 1.4 which had required format changes; in fact the formats are
very similar in all but a few cases. So I wanted to get JAD to
try to decompile the file anyway, to see if it would work. Unfortunately JAD absolutely refused to have anything to do with the file because it didn't like the version number. In order to work around this, I used a binary editor to manually alter the version number in the class file to basically lie and say it was generated by 1.3. Then I ran JAD and got perfect results - I was right, the version difference did not actually affect the file I was working on. So the whole business about refusing to work on the file because of the version number was just a big inconvenience for me, and I would have greatly preferred that JAD had just issued a warning rather than refusing to work.
OK, that's for a "version number" rather than a "magic number" - the latter is more likely to be intended as a
unique value for anything remotely resembling a data file using the documented file format. However "more likely" != "certainly".
Really, either solution is acceptable to me here - I just have a preference for "warn" rather than "fail". If Bodgett & Scarper want different behavior, they need to learn to write better specs. The issue is documented in the design docs, and (if this were a real-world project) it would be trivial to change the behavior to "fail" later once someone verifies that there really is one and only one possible magic cookie value.