[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Jeff Blakeney writes ...
> 
> On Sat, 10 Jul 1999 19:10:07 -0500, Rubywand <rubywand@swbell.net>
> wrote:
> 
> >     My guess is that Windows or Netscape must maintain some kind of temporary
> >'junk file' copy of downloads. When a file is downloaded in Text mode, the
> >unmodified copy goes into this temp file and into a buffer. Once the download
> >is finished, the line enders are 'fixed' in the buffer and the file appears in
> >your directory. The unmodified copy remains in the junk file (maybe for weeks)
> >until its portion of the cache is eventually over-written.
> 
> As far as I know, but I'm not 100% sure, the end of line translation
> is done by the server you are connected to before it sends the data to
> you.  They had to write the servers to work correctly with dumb
> terminals back then so they had to assume that the client could not do
> any processing of data after the transfer.  I don't know if this has
> changed recently but I see no reason why it would.
>

     I do not know either. (Still, it seems likely that, under http, files are not
modified during transfer-- instead, MIME types are used to tell the downloading
system about processing.)

 
> >     This would explain why Uncook sometimes does not work. Aside from a few
> >downloads which are screwed up to begin with, it would not work if applied to
> >an old download for which the original has been over-written.
> 
> I think it is more likely that the method used to tell the server what
> your end lof line character is and the machine the server is running
> on are far more likely to cause screw ups every now and then.  If the
> server thinks you are a Mac instead of a PC it will translate the end
> of line characters wrong.  If the server is running on a Mac instead
> of a unix system, then uncook, if it assumes that CR/LF should be
> changed to just LF as used by unix, will mess up because it should be
> translating CR/LF to CR instead.

     Possibly; but, it seems unlikely that Uncook works in such a way.

     The problem is that, having just the finished file to work with, no expert
system would be able to reliably determine which line ender pairs were newly
created and which belonged in the original. The guess that some non-processed copy
of the downloaded file must be saved somewhere on the downloading system is based
on the observation that there seems to be no alternative explanation for Uncook's
success.



Rubywand