On 2013-06-10, Emmanuel Bourg wrote:
> Le 10/06/2013 11:02, Torsten Curdt a écrit :
>> Of course we could be user friendly and add the heuristic but that's
>> like opening a can of worms.
> I agree. And considering the format has been deprecated in favor of xz I
> wouldn't worry too much.
Sound
Le 10/06/2013 11:02, Torsten Curdt a écrit :
> Of course we could be user friendly and add the heuristic but that's
> like opening a can of worms.
I agree. And considering the format has been deprecated in favor of xz I
wouldn't worry too much.
Emmanuel Bourg
signature.asc
Description: Open
On 2013-06-10, Damjan Jovanovic wrote:
> The problem is not unique to LZMA, and since LZMA can contain almost
> any bytes at the beginning, it could also be misdetected as another
> compression format.
Right, that's why I suggested to put LZMA detection at the end, if at
all.
> If we can't autod
> We could do something similar by placing the LZMA check at the end in
> the CompressorStreamFactory's autodetect method and perform the same
> plausibility checks on the input. This would still run the risk of
> false positives and - maybe less likely - false negatives. Do we want
> to do somet
On Mon, Jun 10, 2013 at 6:25 AM, Stefan Bodewig wrote:
> Hi,
>
> when I added support for decompressing .lzma files I left out matches()
> and you can only get an LZMACompressorInputStream from
> CompressorStreamFactory if you use the version that explicitly specifies
> the format.
>
> The reason
Hi,
when I added support for decompressing .lzma files I left out matches()
and you can only get an LZMACompressorInputStream from
CompressorStreamFactory if you use the version that explicitly specifies
the format.
The reason is that the old .lzma format doesn't have any sort of
signature at all
