Oh! I thought it was a SquishMail problem.
Are you talking about the flo problem?
No I were talking about the zone 7223 problem.. But I
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
* Origin: Top Hat 2 BBS (1:343/41)