It sounds like you know what the problem is, so can you send a patch that fixes this? Remember to add a test to zero_copy_stream_test.cc.
On Sun, Oct 18, 2009 at 9:27 AM, Jacob Rief <[email protected]> wrote: > > I use protobuf to write self delimited messages to a file. When I use > FileOutputStream, I can close the stream, reopen it at a later time > for writing, closing it again and then parse the whole file. When I > try to do the same job after writing with GzipOutputStream, than > parsing with GzipInputStream, I can read up to the end of the first > chunk, but then CodedInputStream::ReadRaw returns false and my > application looses its sync. If however I first uncompress the written > file with gunzip and then use FileInputStream to decode it, everything > works fine. Also, if I lseek the file descriptor onto the beginning of > the second chunk (1f 8b 08 ...) and create a new GzipInputStream > object using that file descriptor, I can read everything. > > I did some debugging and found out that when I use a zipped file with > one chunk (normal case) and hit the eof in GzipInputStream::Next > Inflate() returns Z_STREAM_END and zcontext_.avail_in is 0. When I do > the same tests with a concatenated file, when reaching the end of the > first chunk, in GzipInputStream::Next Inflate() returns Z_STREAM_END > and zcontext_.avail_in is 1129, which means that the zlib has some > unprocessed bytes in the input buffer. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
