LZIP is a competing LZMA compression. (see: http://www.nongnu.org/lzip/lzip.html) it is gaining ground, especially since it made it into a major linux magazine (Linux Format I believe). There are even some lzma utilities that support processing of lzip archives. (see: http://lists.gnu.org/archive/html/lzip-bug/2008-12/msg00001.html) I have attached my first-round patch and adding lzip support to xarchiver, but there is still a problem to deal with. This problem is that the short-hand for lzip: .tlz is the same as the lzma short hand: .tlz This means that processing .tlz files, one can expect errors when lzma is chosen when the file is actually compressed in lzip (and vice-versa). So there is still some more patching to do, I just am uncertain as to how it needs to get done.
Created attachment 2067 Lzip info file
Thank you for your nice patch. Your contributions are always appreciated. To handle .tlz files and avoid errors if the archive was compressed with lzma what if a check on its magic header is performed? Please see window.c:1105 in xarchiver sources. This way you know with which archives (lzma or lzip) the file was compressed and you behave accordingly. What do you think? PS. The header for LZIP compressed files is: `Magic bytes' A four byte string, identifying the file type, with the value "LZIP". See attached file.
(In reply to comment #2) > Thank you for your nice patch. Your contributions are always appreciated. To > handle .tlz files and avoid errors if the archive was compressed with lzma what > if a check on its magic header is performed? Please see window.c:1105 in > xarchiver sources. This way you know with which archives (lzma or lzip) the > file was compressed and you behave accordingly. What do you think? > > PS. The header for LZIP compressed files is: > > `Magic bytes' > A four byte string, identifying the file type, with the value > "LZIP". > > See attached file. Did I forget to attach the patch, it seems to be missing from the bug report. Anyway.. I did do that with my patch, however a problem still occurs with the following line I used to setup the open_archive function call: src/main.c:305: open_archive[XARCHIVETYPE_LZIP] = &xa_open_bzip2_lzma; Where xa_open_bzip2_lzma has the following pertinent code: else if (g_str_has_suffix(archive->escaped_path,".tar.lzma") || g_str_has_suffix (archive->escaped_path,".tlz")) { archive->type = XARCHIVETYPE_TAR_LZMA; archive->format = "TAR.LZMA"; archive->delete = delete[archive->type]; archive->add = add[archive->type]; archive->extract = extract[archive->type]; xa_open_tar_compressed_file(archive); } As I am typing this I am noticing that this is uncovering a bug. A bzip2, lzma, lzop, and (now) lzip file can be properly detected by the magic header, even if the file extension is missing, weird, or incorrect. When the file extension is different than what it should be (or conflicts in the case of lzip & lzma) then an incorrect decompresser is chosen or a "not supported" is given to the user because the file extension gets used over the magic header. To prove the test case, I made a .tar.bz2 file of the xarchiver source. I then renamed the .tar.bz2 file to .tlz xarchiver will try to open it as a .tlz file even though the extension will work. I then made a .tar.gzip file of the xarchiver source. The .tar.gzip was renamed .tlz as well. xarchiver properly called gunzip for the .tlz file. Of course, here gunzip only checks file extension and not the magic header. This causes gunzip to fail. The problem lies in how you recycled the bzip2 and lzma code (and then I later also recycled to create the patch for lzop and now the lzip patch in discussion) xa_open_bzip2_lzma in bzip2.c are all checking the file extension before applying additional settings. This assumes the file extension is what it is expected to be. In the cases of lzma and lzip, because their names conflict this causes the if/then/else to choose the first one of the two that is tested for first. Somehow, the gzip.c code is able to cope with improper, undefined, or unusual extensions, but the bzip2.c code is not. A possible fix that I can think of would be to split each of these algorithms into separate functions so that you have gzip.c, bzip2.c, lzma.c, lzop.c, and so on.. Then have another source file generic.c (for lack of a better name), that contains as much of the code that was shared between lzma, bzip2, lzop, lzip, and even gzip code. This way the code could still be recycled keep the program/binary file sizes down.
(In reply to comment #3) > Did I forget to attach the patch, it seems to be missing from the bug report. Yes ;) > A possible fix that I can think of would be to split each of these algorithms > into separate functions so that you have gzip.c, bzip2.c, lzma.c, lzop.c, and > so on.. Kevin, thank you for the time spent on Xarchiver. I would appreciate if you could the above so to apply your patch and have Xarchiver supports another archive format.
Created attachment 2068 Proposed patch to add lzip support to xarchiver (conflicts with lzma's .tlz)
Created attachment 2071 Lzip Support patch #2, with working lzma/lzip conflict resolution I reworked the patch after looking the code over in detail. I chose the simple route of making as few changes as possible. This patch now checks to see if the magic header had revealed whether or not the archive format was lzip. When the .tlz conflict occurs, the patch favors lzma if the magic header is missing otherwise it uses the information gleaned by the magic header to decide whether or not the .tlz was lzip or lzma.
(In reply to comment #6) > This patch now checks to see if the magic header had revealed whether or not > the archive format was lzip. > > When the .tlz conflict occurs, the patch favors lzma if the magic header is > missing otherwise it uses the information gleaned by the magic header to decide > whether or not the .tlz was lzip or lzma. Good job indeed Kevin! Thank you for your kind contribution. I will review the patch as soon as possible and apply it.
Xarchiver is no longer hosted on the xfce repos - it's now at http://xarchiver.sourceforge.net/ If this bug is still valid, please file it there.