Re: LYNX-DEV lynx-386 filename problem

[Klaus Weide]

On Mon, 22 Sep 1997, Doug Kaufman wrote:

> > DOS filenames can NEVER have 2 "." in them.  Suffixes such as .txt.gz,
> > .bin.gz, .htm.Z, etc. can not be written to the filesystem. 

But what happens when you try to write such a file, for example
"blah.html.gz"?  I supposes it gets silently truncated and becomes
"BLAH.HTM"?  What about "blah.o.Z"?

> Here is some more information on the behavior of gzip under DOS.  If
> the file to be compressed has no suffix, it adds ".gz".  If a suffix
> already exists, it adds "z", if the suffix is one or two characters
> long.  If the suffix is 3 characters, it substitutes "z" for  the third
> character in the suffix.  On decompression, the original name is
> restored if the "-N" flag is present; otherwise it removes the final "z"
> or the ".gz".
> 
> Is this behavior consistent with what the lynx code expects?

What gzip does for compression doesn't really matter as far as Lynx is
concerned.  For decompression, this is what is expected (for unix):

 - A file "blah.html.gz" is created, written, and closed.
 - "gzip -d blah.html.gz" is invoked via system.
 - Lynx tries to open "blah.html.gz" for reading; if that succeeds, it is
   assumed that decompression has failed, so error message & give up.
 - Assume the new file is "blah.html".  It will be opend for reading by
   Lynx (or, in case we didn't have a HTML file but e.g. "blah.gif.gz",
   and a viewer is defined for image/gif, we now have presumably "blah.gif"
   and that name is passed to the viewer).

For a unix compressed file, replace ".gz" with ".Z" and "gzip -d" with
"uncompress".  (Is there actually such a thing for DOS?  I think "gzip -d"
should also work for this, but userdefs.h doesn't use it.)

The above is actually NOT what happens (for a gzipped file) if you have
compiled with zlib, and we are dealing with a type handled internally
(like text/html).  In that case gzip isn't called and we just have

 - A file "blah.html.gz" is created, written, and closed.
 - Lynx tries to open "blah.html.gz" for reading; if that doesn't succeed,
   fail; otherwise close it and open again with gzopen() from zlib 
   and start reading.
 
Actually "blah" is "/tmp/LnnnnnnTMP" or similar, which probably is too long
for DOS (depends on what getpid() does in DJGPP).

So what does gzip -d on DOS actually do in these cases?  I.e. when it
is gven a filenname argument which is too long.  Assume -N is not in
effect.

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;