BJ> With Wes's decision to put a number of configuration files in
 BJ> /var/max/etc instead of /var/max (by default), there are already a
 BJ> number of items that don't work exactly like the DOS, OS/2 and Win32
 BJ> version.  Also, the current path "kludge" fix has left me
needing to
 BJ> use full path specifications in places where I should be relative to
 BJ> either /var/max or /var/max/etc, but I haven't gotten relative paths
 BJ> to work....  I've ignored the problem so far by having full paths
 BJ> specified in places that I normally wouldn't.....

 MT> Well there's still opportunity for improvement before 
 MT> things are done in this regard.  Surely relative paths 
 MT> are no less valuable on Linux than other platforms.

Definately.  But it is a lower priority than getting other things working
that don't work at all vs fixing know issues with something partially
working at this time....  All a matter of priorities.  Would you like to go
after the path issues within the code, taking care to keep both DOS, OS/2,
Win32 and Linux / Unix file name and path conventions in mind?

 BJ> (or get caught in debugging) on those platforms.  It does catch us on
 BJ> the Unix / Linux platforms, where file names are (normally) case
 BJ> sensitive....

 MT> Understood, though personally I've been content to live 
 MT> with DOS 8.3 conventions even where my file systems 
 MT> offers support for long filenames and/or mixed 
 MT> case...simply because it is the lowest common 
 MT> denominator and always works for all of my 
 MT> environments.  I certainly wouldn't want to deny 
 MT> someone else the opportunity to create 128-char 12-
 MT> layer paths in mixed case if that's what they wanted, though. :)

Two things are biting us concerning file specifications at this time in a
sometimes major way.  (1)  Case sensitivity, in that sometimes case of file
names and/or paths wasn't always consistant in the code, and not previously
caught due to the OS's that were previously used.  (2) The parsing of path
name parts (i.e. the / vs \ issue).  

Both of these items still bite weather we adhear to the 8.3 naming
convention or not....  And we have yet to address the 8.3 naming convention
that exists in the file areas.  [Note that while OS/2 and Win32 platforms
support long file names, the Maximus BBS file areas do not support such for
the upload / download files.]  Yes, this is an area that needs work.  The
message side of the BBS has supported long file names for some time, and
I've used that on the OS/2 version of Maximus....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01