Re: LYNX-DEV lynx-386 filename problem

[Klaus Weide]

On Sun, 21 Sep 1997, Doug Kaufman wrote:

>  On Fri, 19 Sep 1997, Gary Turner wrote (to me):
>  
>  > (b) nprint ( which is a novell network print program ) will quite 
>  > happily take a mix of / and \, but will say 'file not found' if you 
>  > give it more than 8 and 3 letters. I suppose that this may be for win 
>  > 95 compatability or something.
> 
> I have tried to go through the code and make it more compatible with the
> DOS 8+3 naming conventions.  I believe that the following changes will
> stop DOS programs from breaking by keeping temporary filenames at 8+3 or
> less.  I also made some changes to code that was putting 2 "." within a
> filename.  I don't really follow where that was being used, but I think
> it was going to break DOS.
> 
> The patch is attached.

Doug,

 Some comments based on looking at your patches (not based on looking
at the code with patches applied, or on testing it):

1. Could you change the patch to HTInit.c so that it doesn't duplicate
   the whole function body?  It would be much easier to see what your
   changes are if you could #ifdef only the relevant lines.

2. For the HTInit.c changes, please consider to not change HTFileInit
   at all, but instead put necessary changes in a mime.typ(es) file.
   That should override or add to whatever is in HTInit.c, be more
   configurable, and much more convenient for testing (no recompilation
   needed for changes).  Also some of the types in HTFileInit are really
   outdated, and the MIME types with spaces in them are questionable
   (they are only used to get a "nicer" display e.g. in FTP listings),
   you shouldn't add more of those.  You are effectively introducing
   some new "conventions" (
     HTSetSuffix(".bcZ",  "application/x-Comp. BAK File",...)  ??
     HTSetSuffix(".gta",  "application/x-gtar",...)            ??? )
   which AFAIK are not used by anyone.

   Maybe the functions HTSetSuffix() and HTFileSuffix() should be modified
   instead (for 8+3 systems).

3. Your changes in HTCompressed() are at odds with HTFileInit().  You
   create suffixes ".hZ", ".hgz", ".tZ", ".tgz", ".bZ", ".bgz" instead of
   ".html.Z", ".html.gz", ".txt.Z", ".txt.gz", ".bin.Z", ".bin.gz" (and
   no change for compressed files of different recognized or
   unrecognized content-types).  HTLoadFile() will not recognize those
   suffixes, or recognize them as something else (esp. ".tgz").

   These are changes that only are effective in situations that you
   probably haven't tested.  You'd have to test with compressed files
   from HTTP, FTP and local file URLs, and it should also make a
   difference whether you have compiled with USE_ZLIB or not (I predict
   more problems without it).  In other words it gets rather messy,
   but I doubt that this change makes things work better in general for
   DOS users.

5. consider using a more specific symbol instead of __DJGPP__ (something
   like DOS_8_3_NAMES...), that would make it much easier to track those
   changes.

6. The (first) change in LYPrint.c where your check for ".htm" won't
   actually work, you'll also have to adapt the ' len -= 5; '.

7. Some other functions that probably need changes for this to work
   somewhat:
   tempname() in LYUtils.c, and HTCheckFnameForCompression() in
   GridText.c.  Probably change_sug_filename() in LYUtils.c.
   There may be others.


How much of a problem *is* there actually, with the current code?  And how
much of it occurs only with programs which have the behavior described
by Gary Turner (above), .i.e. not ignoring suffix characters after the
third character?  In which situations, and with which file types, do
the problems occur?

I think (IMHO) concrete problems should be identified, and then we can try
to solve them, rather than just trying to make changes which look right
for DOS on the surface (but it's not clear whether they are (a) necessary
(b) sufficient (c) create other problems).

For example, *if* there is only a problem with calling external programs
(VIEWER, PRINTER, ??), it *may* be better to just shorten the suffix
(AND filename proper!) where this actually occurs; or even just adopt the
helper apps to do that.  If there is a more general problem, then maybe
DOS needs a wrapper function around fopen() (which would call fopen()
after munging the filename) [only for opening with "w"?], and/or some
changes to other functions (see 2. and 7. above).  But AFAIK the problems
haven't been properly identified or discussed.

A starting point for this would be that users have to learn to make usable
and detailed problem reports to the list (or to whover wants to support
the code for DOS).

   Klaus

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