Evgeny Kotkov <evgeny.kotkov_at_visualsvn.com> writes:
> 1) We cannot really use svn_stream_flush(TRUE) + svn_stream_close() with
> a compressed stream that is chained over a file stream or a stream that we
> expect to be consistent with the underlying device. A compressed stream
> writes the final data chunk in close_handler_gz() and calls deflate() with
> Z_FINISH. In this case, closing the compressed stream would require a
> full flush of the underlying stream in order to guarantee consistency.
> Leaving the compressed streams without a flush handler implementation is
> also a poor choice because the caller of svn_stream_flush() would have to
> know the details about the given stream in order to avoid receiving the
> SVN_ERR_STREAM_NOT_SUPPORTED error.
> I believe that this is an example where achieving the proper behavior with
> files is simple, but abstracting it with streams is a challenge.
I still prefer the stream patch I posted earlier, and it can be extended
to support compressed streams. Something like:
if (stream->close_fn == close_handler_apr)
else if (stream->close_fn == close_handler_gz)
struct zbaton *zbaton = stream->baton;
else if (stream->close_fn != close_handler_flush)
return svn_error_create(SVN_ERR_STREAM_NOT_SUPPORTED, NULL,
_("No closing file to flush"));
That only allows flushing the stream on close but I do not see any need
at present to support flushing at arbitrary positions.
I don't insist on this solution, if people think the file code is better
that is OK.
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2015-05-28 12:01:46 CEST