Re: SHK/GSCII Bug (was Re: Python...)

[rubywand@aol.com (RUBYWAND)]

In article <4o5tch$ini@gap.cco.caltech.edu>, nathan@cco.caltech.edu
(Nathan Mates) writes:

>....  if the file seems to have been
>damaged from the start, as described above, trying to 'fix' some
>decompressor wouldn't do much at all. The fact that _both_ GSHK and
>ShrinkII on the Macintosh (which is most likely based on slightly
>different source code) couldn't deal with it usually indicates a bad
>file, not a program bug.
>
>   If I'm to be hunting a bug, I want some hard info on it, especially
>how to reproduce it at will. Given a description, time and inclination
>to do something about it, I might be able to do something about it.
>

     The GSCII (probably not SHK) bug cropped up when dealing with
non-damaged files. The files were GSCII encoded and then decoded as a
check. The decoded stuff was corrupted. It's too bad some record of the
files involved was not kept, because the bug does not seem to ruin most
encodes.  As soon as a good example case or some alternative explanation
is available, more detailed info will be posted.

     For now, users who employ GSCII (or Binscii) can do a decode to check
for corruption before sending the GSCII-ed stuff. (If the decode produces
messed up files, removing text files may help-- the text can be sent
separately.) This should reduce the large number of unexplained bad
downloads of GSCII-ed and Binscii-ed materials. 



Rubywand