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.

Bo:

I think I've seen two squish issues metioned recently.  The *.Flo vs *.flo
file name issue is the one I was wondering if you could look at. 
Specifically, check for where squish changes the file name to set the
different *.?lo file names.  I bet we lower case the file name and then in
some spot either fail a check against a capital letter for the ? position
or change the packet type using an upper case character after the file name
may have been converted.  Or we may have a file rename going on that
doesn't use the kludge that forces a lower case file name, or something
similar......  Probably nasty to look for.  Maybe you could add debug
logging code of when files are opened, closed, renamed, etc. and then we
could just monitor the log for what activity has happened and trace down
the culprit from there....

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

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01