Hello Bob.

05 Nov 03 23:20, you wrote to me:

 BS>>> Oh! I thought it was a SquishMail problem.

 SR>>  Are you talking about the flo problem?

 BS>> No I were talking about the zone 7223 problem.. But I
 BS>> can't reproduce the flo/Flo problem.

 BJ> Bo:

 BJ> I think I've seen two squish issues metioned recently.  The *.Flo vs
 BJ> *.flo file name issue is the one I was wondering if you could look at.
 BJ> Specifically, check for where squish changes the file name to set the
 BJ> different *.?lo file names.

The actualy problem is that Scott is using the flavour as the first
charecter in the flo-name so he used something familear with:

        sprintf(floname, ".%clo", flavour);

Unfortionally is he doing it alot of times. :-(

 BJ> I bet we lower case the file name and
 BJ> then in some spot either fail a check against a capital letter for the
 BJ> ? position or change the packet type using an upper case character
 BJ> after the file name may have been converted.  Or we may have a file
 BJ> rename going on that doesn't use the kludge that forces a lower case
 BJ> file name, or something similar......  Probably nasty to look for.
 BJ> Maybe you could add debug logging code of when files are opened,
 BJ> closed, renamed, etc. and then we could just monitor the log for what
 BJ> activity has happened and trace down the culprit from there....

He's doing it many times in the code, so this way it's beeing very defficult.

 BJ> On the zone issue, Squish is limited to FFF (base 16) for the maximus
 BJ> zone number, based on the 8.3 limit of the old FAT file system and how
 BJ> binkley style outbound works.  Let's see....  FFF works out to....
 BJ> Ah....  4095.  So, yes, any zone number above 4095 (decimal) is not
 BJ> legal in a binkley style outbound, at least the original implmentation
 BJ> on a FAT style (DOS 8.3 file name) system.  Yes, most Linux and Unix
 BJ> file systems, and HPFS and JSF under OS/2 and some windows extensions
 BJ> to the DOS 8.3 stuff would allow us to go past that, but the original
 BJ> design limited the zone number to three hex digits.....  So, the 7723
 BJ> zone number is a non-problem from my perspective.  Who ever chose that
 BJ> zone number won't be supported by Binkley Style Outbound areas if the
 BJ> person is in any other zone, and the other zone is the primary zone.

3 x hecadecimal counts, gives only 4096! So in that way is zone 7223 not supported!

Damn it! ;-)

Maybe amiga outbound style can do it better?

Bo

--- GoldED+/LNX 1.1.5-31012