Fw: new file format

["Gianluca Varenni" <gianluca.varenni () polito it>]

----- Original Message ----- 
From: "Guy Harris" <guy () alum mit edu>
To: "Gianluca Varenni" <gianluca.varenni () polito it>
Cc: "Loris Degioanni" <ldegioanni () ucdavis edu>; "Fulvio Risso"
<fulvio.risso () polito it>; "Michael Richardson" <mcr () sandelman ottawa on ca>
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.