> What happens when an older version of zbackup tries to read a bundle
compressed with lzo? Would it just fail because the compressed data does
not look like lzma?

I assume that lzma will detect that it isn't looking at valid data. It
has its own header, hasn't it? I suppose that the data would at least
fail some checksums. To be honest, I haven't tested that.


> I propose to set the version to 2 in the header when the compression
method is different from the original 'lzma', and otherwise use version 1.

That would work from a functional point of view, but I think it is quite
unclean. In my opinion, the file version should be about the fields that
are present (or their interpretation) and not their values.


I think I should find out what an old version of zbackup does if it
encounters an lzo file. I suggest that we leave it my way, if the
behaviour is reasonable. If it is something like "lzma decompression
failed", we could add a note to the README, so people will find it, if
they cannot figure the message out themselves. What do you think about that?

On 08.10.2013 22:36, Konstantin Isakov wrote:
>
> In bundle.cc:
>
> > @@ -33,8 +33,10 @@ void Creator::write( std::string const & fileName, EncryptionKey const & key )
> >  
> >    os.writeRandomIv();
> >  
> > -  FileHeader header;
> > +  BundleFileHeader header;
> >    header.set_version( FileFormatVersion );
>
> What happens when an older version of zbackup tries to read a bundle
> compressed with lzo? Would it just fail because the compressed data
> does not look like lzma?
>
> I propose to set the version to 2 in the header when the compression
> method is different from the original 'lzma', and otherwise use
> version 1. This way older zbackup versions would be able to decompress
> bundles created with the newer versions as long as they still use
> 'lzma', but in all other cases it would fail with the more informative
> 'incompatible version' message.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/zbackup/zbackup/pull/9/files#r6839105>.
>