About Uncook- "a great lil' Utility too!!"

[Rubywand <rubywand@swbell.net>]

Jeff Blakeney writes ...
> 
> On 8 Jul 1999 20:50:41 GMT, apple2pd@ground.ecn.uiowa.edu (ISCA
> AppleII Librarian) wrote:
> 
> >Jeff, if Apple binary files are having end-of-line conversions being done
> >then you are NOT transferring in binary mode.  End-of-line conversions
> >only happen in text transfers.  Try to fix your transfer program or
> >browser or change to another application to do your file transfers.
> 
> For the most part I haven't had problems transferring Apple II files
> myself.  It just seems to me that the corruption that sometimes occurs
> happens because the browser or server don't send the file in binary
> mode but in text mode instead which causes end of line characters to
> be changed.  I don't think any web servers ever send data over a 7 bit
> connection but I haven't read the RFC for http yet so I'm not sure.
> 
> I was wondering how the uncook program was fixing files if it didn't
> know what end of line character translation was done during the
> transfer.
> 
 ....

     Wondered about the same thing.

     The usual Text mode download corruption seems to be insertion of a Return ($0D)
before any Line-feed ($0A) which does not already have a preceding $0D.

     The $0D $0A pair is not super-common in most Apple II files; but, it seems to
usually occur at least 2-3 times in files of moderate size. If Uncook just goes
through a downloaded file and rips out $0D's in front of $0A's, how does it know the
difference between bad $0D $0A pairs and $0D $0A pairs which belong in the file?
 
     Still, GS Ed says Uncook works most of the time; so, I tried an experiment.

     Two Dsk files (each of which contain legitimate $0D $0A pairs) were ftp uploaded
to a site and, then, downloaded via browser under an http connection. Both files
arrived corrupted (length was greater than the standard 143,360 bytes).

     I tried Uncook on each file. The result was a 143,360-byte file in each case!
Both files seemed to boot and work correctly on AppleWin, too. Moving the files to
the GS and running a Copy II Plus 9.1 Compare Files check showed that each Uncooked
file is identical to its corresponding (good) original.


     It looks like Uncook (somehow) works-- at least most of the time. (Thanks for a
neat util discovery, GS Ed!)



Rubywand