Indexing of 7-Zip archives created with default LZMA2 compression fails
Desktop search application
Brought to you by:
qforce
Indexing of 7-Zip archives created with default LZMA2 compression fails, it says 'not an archive', tested with DocFetcher-1.1.18 and archives created with the latest 7-Zip 16.04. It only produces errors like this:
1 test_LZMA2.7z 2 test01.pdf ### Error: test01.pdf 3 test02.pdf ### Error: test02.pdf Total elapsed time: 0 s
Error: End-of-File, expected line E:\test_LZMA2.7z\test01.pdf Error: End-of-File, expected line E:\test_LZMA2.7z\test02.pdf
Note: I posted this under 'Bugs' and not 'Feature requests', because LZMA2 is part of 7-Zip since 2009 already, v9.04 beta from 2009-05-30, and it is the default compression method for .7z archives since v9.30 alpha from 2012-10-26. Majority of archives created with 7-Zip today use LZMA2 compression. More info: http://www.7-zip.org/history.txt
Attaching 2 small files, one created with old LZMA, another with default LZMA2. Text file inside LZMA2 archive won't be indexed.
Anonymous
Update: sometimes it says ''Not an archive", other times it says "Error: End-of-File, expected line".
Hi,
unfortunately, we're not going to get anywhere with this anytime soon. The thing is, DocFetcher's 7-zip support is based on the only available Java implementation of 7-zip, which is here. That project hasn't been updated for the last 10 years, so no update is to be expected in the future. Also, note that the DocFetcher project is currently not being actively developed, so rebuilding the 7-zip support on something else is no option at the moment.
Best regards
q:-) <= Quang
Maybe XZ for Java could help somehow, it supports LZMA2,and it is still maintained project. It can open .xz and older .lzma files, regardless if they use LZMA1 or LZMA2, so it could be added for those formats. On non-Windows platforms .xz is used very often.
http://tukaani.org/xz/java.html