----- Original Message ----- From: "Guy Harris" <[EMAIL PROTECTED]> To: "Gianluca Varenni" <[EMAIL PROTECTED]> Cc: "Loris Degioanni" <[EMAIL PROTECTED]>; "Fulvio Risso" <[EMAIL PROTECTED]>; "Michael Richardson" <[EMAIL PROTECTED]> Sent: Friday, July 23, 2004 12:14 PM Subject: Re: new file format
> > On Jul 23, 2004, at 11:57 AM, Gianluca Varenni wrote: > > > If the file is transfered from win to unix in ASCII mode, the file > > should > > become > > > > \n\n\r .......... In this case we recognize the first three characters > > "\n\n\r", try to convert the first 12 bytes from unix-ascii to > > win-ascii, > > and check the byte order magic at bytes 8-11. > > > > If the file is transfered from unix to win in ascii mode, the file > > should > > become > > \r\r\n\r\n\r ....... In this case we recognize (for example) the first > > three > > chars "\r\r\n" and try to convert the first n characters (24 chars??) > > from > > win-ascii to unix-ascii, and check the byte order magic at bytes 8-11. > > Is there always only one way of converting between UN*X format and > Windows format? Or could information be lost, even for this particular > case, in a way that prevents it from being reclaimed? > > One possibility would be to assume that if the byte-order magic appears > within some number of bytes of the proper position the file was a valid > dump file transferred in ASCII order. I suspect that, in a UN*X to > Windows transfer, at most every \n would become a \r, so that'd mean > that the magic number would be at most 6 bytes after the correct > position (if the block size *happened* to be 168430090, i.e. > 0x0a0a0a0a, or \n\n\n\n) and, in a Windows to UN*X transfer, at most > every \r would be deleted, so that'd mean that the magic number would > be at most 6 bytes before the correct position (if the block size > *happened* to be 218959117, i.e. 0x0d0d0d0d, or \r\r\r\r), so if the > byte-order magic appears (in either byte order) in an offset between 2 > (8-6) and 14 (8+6), assume the file was a valid file transferred in > ASCII mode. > > I.e., don't bother trying to recover the block type and block size, > just check for a byte-order magic in any of the places where it could > possibly be. > > (We'd do the same with subsequent section header blocks, and say > "sorry, some part of this file was transferred in ASCII mode" or > "somebody concatenated to a file another file transferred in ASCII > mode".) > > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
