http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1711
------- Comment #8 from guy@xxxxxxxxxxxx 2007-11-06 19:46 GMT -------
Most capture file formats have a "magic number". Those capture file formats
are checked for first; if the file has the magic number for a format, the file
is treated as being in that format.
After that, file formats that don't have a "magic number", which tend to be
text file formats - the old {Ether,Token,Airo}Peek format and the ERF format
are exceptions, being binary formats that unfortunately lack a magic number
(the old *Peek formats, I guess, were originally for classic Mac applications
and relied on the type and creator codes in the resource fork, but that gets
lost in most copies between machines). Those formats are checked for by
heuristics.
The sequence in which the tests are done could be changed for the heuristic
formats (there's not much point in changing the sequence for the magic number
formats). The best sequence is to do the tests with the strongest heuristics
(the ones most likely not to match files that aren't in the specified format)
first. However, we currently put the text-based formats last, just in case you
have a capture of a Telnet session to one of the devices that generates that
text-based format.
The only way to ensure that a heuristic test never match a file if that file
cannot be processed without errors would be to have the heuristic read the
entire file. For a large capture - as an ERF file can be - that could be very
expensive, so we don't do that. It would be *REALLY* ugly to have Wireshark,
if it gets an error reading a file, go back and try the file formats after the
one it had tried - and that could mean that a damaged file of the format in
question could be mis-reported as, for example, a damaged file of some other
format.
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
