…by adding new struct builder functions (to preserve backward compatibility).
Basically, passing the option LZMA_CONCATENATED to the xz library will make it process the successive xz streams.
If someone wants to process one xz stream followed by non-xz data, it cannot be done with xz::read::XzDecoder: it will create an internal BufReader which may consume data after the xz stream. Because this BufReader is not accessible by the caller, the additional consumed data will also not be available to the caller.
Therefore, for such a scenario, one can use a xz::bufread::XzDecoder and pass it a BufReader.
Closed because of conflicts (I did not notice that the master had evolved). I reworked the code in #31 starting from master (in order to have a nice commit history without any useless conflict resolution)
…by adding new struct builder functions (to preserve backward compatibility).
Basically, passing the option
LZMA_CONCATENATED
to the xz library will make it process the successive xz streams. If someone wants to process one xz stream followed by non-xz data, it cannot be done withxz::read::XzDecoder
: it will create an internalBufReader
which may consume data after the xz stream. Because thisBufReader
is not accessible by the caller, the additional consumed data will also not be available to the caller. Therefore, for such a scenario, one can use axz::bufread::XzDecoder
and pass it aBufReader
.