Re: Hunt the Wumpus

Jeff Blakeney

To: Andy McFadden
On Thu, 8 May 2008 05:18:24 +0000, Andy McFadden wrote:

> Michael J. Mahon <mjmahon@aol.com> wrote:
>>
>> And his Master Disk Catalog listing is searchable! ;-)
>
> And available for download from http://faddensoftware.com/ ...

I just downloaded the MDC listings but they seem to be uncompressed text
files with a .gz extensions so when I transferred them, the line feeds
were not converted to carriage return/line feed (which I believe is
something HTTP transfers will do) and I had to rename the files to be
able to open them.

Is there a reason this was done or did something go amiss?
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.

mark lewis

To: Jeff Blakeney

JB> I just downloaded the MDC listings but they seem to be uncompressed
JB> text files with a .gz extensions so when I transferred them, the
JB> line feeds were not converted to carriage return/line feed (which I
JB> believe is something HTTP transfers will do)

nope... FTP does this if binary transfers are not used... but the FTP must also
be able to know what is used on both ends of the connection...

)\/(ark


* Origin: (1:3634/12)
--- Synchronet 3.15a-Win32 NewsLink 1.85
* Derby City Online - Louisville, KY - telnet://derbycitybbs.com

mark lewis

To: Jeff Blakeney

JB> I just downloaded the MDC listings but they seem to be uncompressed
JB> text files with a .gz extensions so when I transferred them, the
JB> line feeds were not converted to carriage return/line feed (which I
JB> believe is something HTTP transfers will do)

ml> nope... FTP does this if binary transfers are not used... but the
ml> FTP must also be able to know what is used on both ends of the
ml> connection...

forgot to add that http is dumb and doesn't have a clue, either... it can't
even keep the original file time and date stamps... FTP can and does in most
cases

)\/(ark


* Origin: (1:3634/12)
--- Synchronet 3.15a-Win32 NewsLink 1.85
* Derby City Online - Louisville, KY - telnet://derbycitybbs.com

Andy McFadden

Jeff Blakeney <jeff.blakeney@a2central.com.remove-gtj-this> wrote:
> I just downloaded the MDC listings but they seem to be uncompressed text
> files with a .gz extensions so when I transferred them, the line feeds
> were not converted to carriage return/line feed (which I believe is
> something HTTP transfers will do) and I had to rename the files to be
> able to open them.
>
> Is there a reason this was done or did something go amiss?

They're stored this way because, combined, they're 20MB and compress down
to 2MB. Most browsers will display the content directly, uncompressing the
gzip on the fly, something that usually doesn't happen for formats like .zip.
The result is a file that should be as easily accessible as uncompressed
text, but can be downloaded in 1/10th of the time.

The ".gz" file extension should not be retained by the browser unless you
download the file, in which case it should still be in gzip format. Anything
that can uncompress gzip should also know how to convert line terminators.

--
Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/

Jeff Blakeney

To: Andy McFadden
On Fri, 9 May 2008 14:38:59 +0000, Andy McFadden wrote:

> Jeff Blakeney <jeff.blakeney@a2central.com.remove-gtj-this> wrote:
>> I just downloaded the MDC listings but they seem to be uncompressed text
>> files with a .gz extensions so when I transferred them, the line feeds
>> were not converted to carriage return/line feed (which I believe is
>> something HTTP transfers will do) and I had to rename the files to be
>> able to open them.
>>
>> Is there a reason this was done or did something go amiss?
>
> They're stored this way because, combined, they're 20MB and compress down
> to 2MB. Most browsers will display the content directly, uncompressing the
> gzip on the fly, something that usually doesn't happen for formats like .zip.
> The result is a file that should be as easily accessible as uncompressed
> text, but can be downloaded in 1/10th of the time.
>
> The ".gz" file extension should not be retained by the browser unless you
> download the file, in which case it should still be in gzip format. Anything
> that can uncompress gzip should also know how to convert line terminators.

I've never heard of any browser automatically uncompressing gzip files.
As gzip isn't a standard Windows archive format, I find it hard to
believe that IE would do this. I know zip files can be explored on my
Windows XP system as if they were folders but gzip files can't.

In this case I used IE 7 and right clicked on the links and chose the
"Save Target As..." option and I ended up with uncompressed files with
..txt.gz extensions. Dropping the .gz extension allowed the file to open
in Notepad just fine except that the end of line characters were
incorrect. I had to open the files in Wordpad and save them to disk
again to fix them.

I'm really getting tired of programs that do things for me that aren't
advertised or even make sense. I asked the browser to save the data
pointed to by a link to a file on my computer. It shouldn't do anything
to the file at all. After thinking about it I realize that there
shouldn't be end of line translating going on in this case as the file
being pointed to is of a binary type.

I went back and left clicked the link and IE gave me the option to open
the file or save it. When I chose open, WinRAR started up and gave me
an error that the archive was either unknown or damaged. This is the
same error I got the first time I tried to open the files I had saved
with the "Save Target As..." option.

When saving the file or opening the file, I should have ended up with a
compressed file on my machine because that is what I told the browser to
transfer.

I've seen sites that have put incorrect extensions on filenames to get
around issues with HTTP servers and I've always found these a bit of a
pain too. This is why I asked is something was amiss. I was thinking
that maybe the extension was just set wrong on the server.

I just did a web search and found a Wikipedia entry on IE 7 that
mentions using Gzip and deflate compression to make it so less data
needs to be transferred from the server. This seems sort of like a less
transparent version of the MNP5 compression used with modems in the
pre-internet days. I used to use MNP5 with a 2400 bps modem to get text
to download at up to 9600 bps and MNP5 was smart enough not to
recompress already compressed data so it would still come down at 2400
bps.

I guess maybe this whole situation is probably just a bug in IE 7.
However, it is reinforcing my dislike of modern operating systems,
computers and their documentation.

Anyway, enough of my ranting. Back to talking about a good system.
Apple II Forever! :-)
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.