• Squish bugs.....

    From Bob Jones@1:343/41 to Bo Simonsen on Wed Nov 5 23:20:48 2003
    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)
  • From Bo Simonsen@2:236/100 to Bob Jones on Thu Nov 6 16:47:08 2003
    Hello Bob.

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

    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.

    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. :-(

    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....

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

    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.

    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
    * Origin: (2:236/100)