BJ> Would you like to go after the path issues within the code, taking
 BJ> care to keep both DOS, OS/2, Win32 and Linux / Unix file name and
 BJ> path conventions in mind?

 MT> Sure I'd like to!  Just don't have the time, tools, or C experience.



 MT> It seems like this cat should've been skinned before, 
 MT> since the Unix conventions were born in the 60's and 
 MT> the rest in the 80's.  Network operating systems have 
 MT> also been handling simultaneous access by mixed clients 
 MT> of the various types as well.  With the other Fido apps 
 MT> already addressing it, there ought to be 
 MT> code/algorithms around for beg/borrow/stealing.  
 MT> Simpler said than done, I know.

Wes has a catch in the code for the / vs \ issue, but it doesn't handle
everything.  For example, string compares and concating parts of paths
together still can bite.  The file open stuff I believe has the
"fix" in place....

 BJ> Both of these items still bite weather we adhear to the 8.3 naming
 BJ> convention or not....

 MT> So if you take care of drive letters and slash 
 MT> directions, what currently supported filenames are 
 MT> invalid as Linux filenames?   This is an area where my 
 MT> perception is that it is only "going for more" that's 
 MT> interfering with retaining what's already there.

Only other problem is case sensitivity issues.  Anything else can be put
off at this time.  I think all drive letter issues are currently handled,
and probably were to start with, since you could use relative paths in
almost all locations...  And that's probably why the "relative
path" stuff isn't working exactly like I expect, because the
"default path" is probably considered "relative" at
this point....  A minor issue....

 BJ> And we have yet to address the 8.3 naming convention that exists
 BJ> in the file areas.  [Note that while OS/2 and Win32 platforms
 BJ> support long file names, the Maximus BBS file areas do not support
 BJ> such for the upload / download files.]  Yes, this is an area that
 BJ> needs work.

 MT> I'm gonna have to take the doom-and-gloom stance on enhancements in this 
 MT> area. There's probably a ton of bigger exchange issues 
 MT> with the limitations of mailer session protocols, file 
 MT> transfer protocols, client support in terminal 
 MT> programs, TICK/HATCH utils etc. that are beyond the 
 MT> scope of the BBS program to address.  It's in the 
 MT> category of huge messages...something that you can hack 
 MT> for limited usage and limited distribution, but one 
 MT> man's "feature" becomes everyone else's "headache" in a 
 MT> network.

I don't intend to change the 8.3 limit in the file areas any time soon. 
Remember Max, can be used outside of Fidonet.  And in testing, BinkP will
transfer long file names between Linux and OS/2 based systems.  [OS/2 based
system is running from HPFS partitions.]  The breaking of 8.3 naming in
TICK/Hatch stuff has been discussed elsewhere, and is only relevent to Max
in that Max doesn't allow more than 8.3 file names in the file areas at
this time.  I think I can go up to about 12 to 14 characters without a
period under OS/2, but the limit is short.....

 BJ> The message side of the BBS has supported long file names for some
 BJ> time, and I've used that on the OS/2 version of Maximus....

 MT> Yes, I've notice that even the longer tagnames of 
 MT> backboned echomail areas are not utilized for backboned 
 MT> file distribution areas (8 chars max, UPPER only). 
 MT> Coincidence?

No.

It's been a while since I looked, but at one time there were TO filebone
definition files.  One was limited to those areas with 8 character (or
less) file bone areas.  There was an additional file with those with 9
character or longer file bone areas because some systems could not handle
the longer file bone areas.

For echo mail, the limit has been longer than 8 characters for many years. 
But there have been glitches in echo areas.  One example is that Squish
uses a CRC hash for echo area names internally.  I remember the first time
an echo got placed on the zone 1 backbone with the same CRC hash as an
already existing echo on the zone 1 backbone.  Squish systems were tossing
echomail between the two echos all over zone 1.  The fix was to change the
new echo area's name by a character, which changed it's CRC value and
solved the issue.  At one point, the folks maintaining the (Zone 1) echo
list were calculating CRC values to make sure future collisions did not
occure.....

Come to think of it, I think this CRC hash issue is still in the Squish
code...  even under Linux.  

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01