----- Original Message ----- From: "Fulvio Risso" <[EMAIL PROTECTED]> To: "Gianluca Varenni" <[EMAIL PROTECTED]>; "Guy Harris" <[EMAIL PROTECTED]> Cc: "Loris Degioanni" <[EMAIL PROTECTED]>; "Michael Richardson" <[EMAIL PROTECTED]> Sent: Friday, July 23, 2004 11:22 PM Subject: RE: new file format
I would like to propose the string "\r\n\r\x1A", so that: - correct byte order, correct ftp transfer ==> "\r\n\r\x1A" - correct byte order, wrong ftp UNIX to Win ==> "\r\n\n\r\" - correct byte order, wrong ftp Win to UNIX ==> "\n\r\x1A\?" - changed byte order, correct ftp transfer ==> "\x1A\r\n\r" - changed byte order, wrong ftp UNIX to Win ==> "\x1A\r\r\n" - changed byte order, wrong ftp Win to UNIX ==> "\x1A\n\r\?" If I'm not making any further mistake, this string should recognize both byte order and correct ascii transfer. Cheers, fulvio > -----Original Message----- > From: Gianluca Varenni [mailto:[EMAIL PROTECTED] > Sent: venerd� 23 luglio 2004 21.34 > To: Guy Harris > Cc: Loris Degioanni; Fulvio Risso; Michael Richardson > Subject: Re: new file format > > > > ----- 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? > > I don't know... > > > > > 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 > > Not sure about that. > > > 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. > > Neither I want to recover the file. > > I like the solution you propose: if the \r\n\n\r is not found at the > beginning of the file, we look for the magic number from byte 2 to byte 14 > of the file. If we find, we report an "ASCII format conversion mismatch" > error (or something like that). > > I think this is the solution to the problem. > > Have a nice day > GV > > > > > > > > (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.
