EOF not detected
jk
I'm trying to decompress a compressed file by applying
"DeflateStream.Read()" from the beginning to the end of the stream. I've
tested this with many files both compressed and not. In the latter case you
normally get an "InvalidDataException" on the first call to "Read()" but not
always. I'm not sure why it doesn't always result in that exception but in
any case, I just tried testing it on an arbitrary ".ncb" file (the same one
created by Visual Studio and sitting in my solution's folder) and
"DeflateStream.Read()" never even detects an EOF condition. It always
returns non-zero so my "Read()" loop never exits. For other invalid files
I've tried this doesn't happen. This is flaky and presumably broken
behaviour to say the least. Any ideas? Thanks.
Peter Duniho
The only justification I can see for DeflateStream.Read() _not_ throwing
an InvalidDataException is if the data looks like a valid compressed
stream, but turns out to have some structural defect that causes a
_correct_ deflate implementation to get stuck. Otherwise, yes...I'd say
that's a bug.
I don't know enough about the particular compression format to know if
it's even possible for a correct deflate implementation to get stuck, nor
do I have specific information about the .ncb file format. If the .ncb
file format is in fact some compressed binary format similar to the
deflate format (it's not uncommon to find binary formats that are really
just some kind of compressed text format), I suppose that might explain
the behavior you're seeing.
But that's a lot of things that all have to be true.
If it _only_ happens with .ncb files, then maybe that's exactly what's
going on. If you can find other files known _not_ to be a compressed
format (deflate or similar), but which still reproduce the problem, then
I'd be more concerned about it.
In any case, without a concise-but-complete code example that reliably
demonstrates the problem, I'm afraid the best one can do is simply agree,
"yes, that sounds broken".
As a work-around, you might try writing a Stream wrapper that you use to
wrap the original data stream (e.g. a FileStream instance), and which you
monitor progress within the original data stream. If, as you call
DeflateStream.Read(), you find that it claims to be making progress (i.e.
it returns a byte count greater than zero) even while the original stream
makes no progress, then you can treat that as an error.
Note that some calls to DeflateStream.Read() won't necessarily result in
data read from the original stream, due to buffering and the compression
itself. But, you can pick some arbitrary threshold that exceeds any
possible compression ratio for the particular compression scheme and if
the "uncompressed" byte count winds up more than that ratio greater than
the bytes read from the original stream, then you've probably got an
invalid input stream.
For that approach, I'd say 100 would be a reasonable, nice round
number...but you may want to experiment. Without knowing more about the
specific compression algorithm's behavior, it's theoretically possible
that while 100-to-1 compression is impossible, you could get runs of data
where you find a 100-to-1 ratio, even as the average compression is much
lower. And of course, for some kinds of data with certain compression
algorithms, even 100-to-1 is theoretically possible (e.g. an RLE-based
compression algorithm with just the right input data).
And of course, if it turns out that there is in fact a bug in the
DeflateStream class, you should definitely report it at Microsoft's
Connect web site.
Pete
Arun
http://www.codeproject.com/KB/cs/SimpleZip.aspx
Thanks
Arun
This will pass too....
jk
> http://www.codeproject.com/KB/cs/SimpleZip.aspx
Thanks. I took a quick look but it's really of no help. My code is basically
the same as MSFT's own examples so at this point it appears there's a bug in
their code. I'll have to implement my own work-around for now. Thanks again.
Angel J. Hernández M.
Cheers,
--
Angel J. Hern�ndez M
MCP,MCAD,MCSD,MCDBA
Microsoft MVP
http://msmvps.com/blogs/angelhernandez
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
http://www.customware.net
Technical Solutions Architect
"jk" <_nospam@_no_spam.com> wrote in message
news:#WI7XZQ9...@TK2MSFTNGP02.phx.gbl...