paq8 have same old version, zpaq not working, lpaq8 is lost.
Zpaq, as said in change log, is for this moment limited to archive with absolute paths, and extract back to absolute paths (skips existing files).
It would be very useful if the executable could accept an output path, currently the archive would be needed to be listed and the command line built specifying the new name for each output file; it could be automated but is very different than the syntax supported by most of other executables.
I hope newer versions of the executable would have a command line more similar to old paq, or to 7z (very good, since very similar to rar's syntax), or to freearc.
I really like that format and I would like to support it at best in future!
However, all PAQ and LPAQ formats previously supported are still supported for browsing and extraction.
The ZPAQ spec only says that file names are optionally stored in the archive. You can do the command line how you want. I wrote zpaq and unzpaq command lines to be a subset of zip, 7zip, rar with commands a (add), x (extract), and l (list). These programs store the file name exactly as you enter it and extract to the same file name unless you give a different name on the command line.
If you want to allow the user to specify the decompressor output directory you can strip off the path and append the directory name. You can also add features like directory creation and traversal, updaing files, deleting files, reorder blocks, store partial file names, etc. If you want to restore creation time, permissions etc. you can use the comment field for that and the reference decoder will ignore it. You can make the archives solid or not by using a block for each file or one block for the whole archive and a segment per file. Or you can make a straight file compressor and not even store the file name. You could have a gzip type interface where the original is deleted and you add a .zpaq extension or whatever. The reference decoder will just ask for the output filename if you don't store it.
The spec just specifies the format. I wrote a minimal archiver just to illustrate the format. I thought it was more important to be portable across OS without any OS specific code that I would need for things like directory creation or traversal or doing fancy things with paths that aren't needed by the spec. I may write an archiver later that does these things and automatically generates models so you don't need a config file. Or maybe I'll write a plain file compressor that takes no options.
Hi, thank you very much for the feedback.
ZPAQ potential is great, and I hope support in PeaZip may give its humble contribution to widespread it.
I fully understand current development priorities are about development of the format itself and its interal algorithms, and about the portability rather than the additional features of the implementation.
What I would find very useful to add to wishlist is an internal path management like in paq (or 7z) which, on extraction, maintains a table of archive's content and replaces the lowest common path with the output path provided by the command line.
In this way IMHO command lines and scripts for ZPAQ could be more compact and readable than with current syntax.
2.7 is now up on SourceForge, 7z was updated to 9.07 and LPAQ8 is now featured as compression format in *PAQ entry.
lpaq8 creates 9 bite file on "maximum"
Working only on "fast" and "default"
BTW, compressing an empty file, lpaq8 should give a 10 byte output, it's very strange it stops at 9 bytes, can you please give more details in order to replicate the incident (system, file, etc) so I or Matt Mahoney can try to understand why lpaq stops in that way?
Thanks in advance.
I didn't write the program but my guess is it runs out of memory after writing the header.