7z, 7za and 7zr in each of those man pages is IMHO spelling mistakes "eXtract and eXclude

p7zip may also have the same issue as mcmilk/7-Zip-zstd#131 and therefore mcmilk/7-Zip-zstd@9378903 and mcmilk/7-Zip-zstd@256e464 may need to be ported to p7zip.

KDE Craft currently uses the old p7zip.
As the project is cross platform we had the best experience with the cmake build system.

In this fork the cmake support is outdated but the hand written makefiles are still maintained.
How about switching to cmake which would, after some initial effort, probably simplify development.

does this project support ARM?if not,do you hava a plan

First of all, thank you for your work on enabling p7zip users to use Zstd with the 7z archive file format.

I would like to use Zstd as a ZIP compression method because of the random access feature present in ZIP but not in 7z:

• For ZIP files, you can extract a file without having to process and decompress the entire archive.
• For 7z files, I believe random access is currently not implemented. However, it looks like the Apache Commons Compress library does have a "slow random access" implementation now. (More info: COMPRESS-342)

In addition, the ZIP File Format Specification by PKWARE Inc. has added the Zstandard compression method ID, and WinZip has added the Zstd method to the ZIP (ZIPX) format (please see this PDF and this webpage).

I found that the compression ratio of a ZIP file using Zstd Level 3 is similar to Deflate64 Level 5, while Zstd Level 3 performs (much) faster than Deflate64 Level 5.

I tried adding Zstd as a ZIP compression method (please see my code here) and it seems I can create, list and update a ZIP file using Zstd.

Some DMG image archives from the Apple ecosystem may have been compressed with the LZFSE (https://en.wikipedia.org/wiki/LZFSE) method.

Some example I came across:
https://github.com/obsproject/obs-studio/releases/download/26.0.2/obs-mac-26.0.2.dmg

Windows version of 7-Zip seems to open these just fine. Most likely due to these changes:

18.05          2018-04-30
-------------------------
- Some improvements in zip, hfs and dmg code. <-- Not sure if relevant for actual LZFSE support
[..]

18.01          2018-01-28
-------------------------
- 7-Zip now can unpack DMG archives that use LZFSE compression method.
[..]

I have Node JS project node-7z-archive that currently pulls 7zip off 7-zip.org, sourceforge, and rudix-mac . Extracts with unar and place binaries within local node js package structure.

The project was using only standalone 7za, just which to full 7z and find there are issues with Linux & Mac OS versions when using full version only. Now it either does not see 7z.so and looking for 7z.dll instead on MacOS, or errors out with unexpected '(' on Linux.

Do you plan on releasing any Mac OS binary?
It would be nice to use a more current and maintained release for these platforms.

https://nvd.nist.gov/vuln/detail/CVE-2018-5996

Insufficient exception handling in the method NCompress::NRar3::CDecoder::Code of 7-Zip before 18.00 and p7zip can lead to multiple memory corruptions within the PPMd code, allows remote attackers to cause a denial of service (segmentation fault) or execute arbitrary code via a crafted RAR archive.--

Hi,
sfx module "7zCon.sfx" not support method ZSTD.

Extracting archive: ./1.sfx
--
Path = ./1.sfx
Type = 7z

ERROR: Unsupported Method : 1.AppImage
                 
Sub items Errors: 1

Archive Errors

Sub items Errors: 1

As you probably know, preserving resource forks / extended attributes can be very important for some files like old Mac fonts... it's important for aliases that are created in Finder to work, it's used to preserve tags for files and folders, for custom icons (if you go to Get Info and apply a custom icon there)... etc.

Before I write some more detailed explanations... just to summarize...

7zip doesn't have to add any special support for resource forks / extended attributes for this to work (since AppleDouble files can be created using other utilities), other than to have an option to add a folder without adding the contents of the folder at the same time and to not sort all files in some alphabetical order when writing them to a .zip archive because the order in which AppleDouble files are added seems to be important for this to work properly and since AppleDouble files have filenames that start with "._", sorting them alphabetically just seems to mess up the order in which they should be added for this to work.

So... 7zip has to do less things than it does to make this work... Just having an option to add folders without adding anything from them (as with zip when you don't add "-r") and to not sort anything in some alphabetical order should be enough to allow users to add a __MACOSX folder with AppleDouble files (which they can create using other utilities) in an order that's compatible with archivers that can recreate resource forks from those.

Users could then sort the files to be added in a correct order with some script or if you want to make it easier for users to add whole folders (instead of adding files one by one in a specific order), you could maybe add a sorting option when someone is adding a __MACOSX folder with AppleDouble files together with some folder, to arrange the files inside the archive in a way that the AppleDouble file for a specific file/folder is written to the archive right after that file/folder. In other words, if you have a folder called "your_folder" and a __MACOSX folder with AppleDouble files for it, to not just add "__MACOSX" folder with everything in it first and "your_folder" with everything it in after that, but when you add a specific file from "your_folder" to the archive to add an "._" AppleDouble file to __MACOSX for that file before adding other files from "your_folder" to the archive.

Now for a more detailed explanation...

I did lots of tests to see what would be needed to preserve the resource forks in a way that seems to be fully compatible with both the Archive Utility and with the unar binary (which is used by different archivers and which seems to be more picky about the order in which AppleDouble files were added).

You can also test it by adding files in a specific order using the zip binary that is included with macOS, since the the zip binary does not seem to do anything special to preserve resource forks / extended attributes... it does not create the AppleDouble files and it does not try to sort them in some specific way... so that's why I'm mentioning it... as an example how to preserve resource forks even when using an archiver that does not really seem to do anything special to preserve them... the same could probably be done with any other archiver that can make a .zip archive, as long as it can add folders without adding everything from them at the same time and if it was just writing files to the archive in the same order as they were added, without trying to sort the files that were already added in some alphabetical order.

To create the __MACOSX folder with AppleDouble files, you can use a command like this (if you want to create it for a folder called "your_folder" in your current directory)

tar cf - your_folder | tar cf - --format cpio --include='*/._*' --include='._*' @- | ditto -x --norsrc - __MACOSX

BTW... Avoid trying to browse the __MACOSX folder in Finder, so .DS_Store files don't get created too inside of it (if that happens, Archive Utility seems to extract it as a regular folder)... Finder doesn't show the "._" AppleDouble files anyway, but you can see them with "ls -a" in Terminal if you want to see those hidden files.

I'm not saying to make 7zip create the __MACOSX folder with AppleDouble files automatically... users can do that themselves if they want... but if someone wants to add those to a .zip archive, so archivers that support recreating resource forks from those files would recreate resource forks upon extraction, those AppleDouble files should be added in a specific order for it to work properly... after you add some file (the "data fork" of it or the file as it is without resource forks / extended attributes), next file that should be written to the archive after it should be the AppleDouble file with resource forks / extended attributes for that file, before adding other files.

In other words...

If you have a folder called "your_folder" and inside of it you have "file1", "file2" and "folder1", inside of "folder1" you have "folder2" and inside of "folder2" you have "file3" (you can tag them all, to make sure they have resource forks / extended attributes) and you create the __MACOSX folder with AppleDouble files for it, the way you add files to a .zip archive in a way that seems fully compatible with both the Archive Utility and the unar binary when it's done with the zip binary from the Terminal is this order... there are two ways to do it that seem to be fully compatible...

1st way... you start by adding an empty folder, then you add the AppleDouble file for that folder, then add the files/folders from that folder and after each file/folder you add, you add the AppleDouble file for that specific file/folder

zip your_folder.zip your_folder/
zip your_folder.zip __MACOSX/._your_folder
zip your_folder.zip your_folder/file1
zip your_folder.zip __MACOSX/your_folder/._file1
zip your_folder.zip your_folder/file2
zip your_folder.zip __MACOSX/your_folder/._file2
zip your_folder.zip your_folder/folder1/
zip your_folder.zip __MACOSX/your_folder/._folder1
zip your_folder.zip your_folder/folder1/folder2/
zip your_folder.zip __MACOSX/your_folder/folder1/._folder2
zip your_folder.zip your_folder/folder1/folder2/file3
zip your_folder.zip __MACOSX/your_folder/folder1/folder2/._file3

Or this... this one seems more like what you get when you list a .zip created by the Archive Utility with 7zip, but it seems maybe less convenient to remember... since you add an empty folder first, then all of it's contents and AppleDouble files for all files and folders inside that folder in correct order... and when you don't have anything else to add to that folder, then you add an AppleDouble file for that folder... with the 1st method it seems easier to just alternative between the "__MACOSX" folder and the other folder...

zip your_folder.zip your_folder/
zip your_folder.zip your_folder/file1
zip your_folder.zip __MACOSX/your_folder/._file1
zip your_folder.zip your_folder/file2
zip your_folder.zip __MACOSX/your_folder/._file2
zip your_folder.zip your_folder/folder1/
zip your_folder.zip your_folder/folder1/folder2/
zip your_folder.zip your_folder/folder1/folder2/file3
zip your_folder.zip __MACOSX/your_folder/folder1/folder2/._file3
zip your_folder.zip __MACOSX/your_folder/folder1/._folder2
zip your_folder.zip __MACOSX/your_folder/._folder1
zip your_folder.zip __MACOSX/._your_folder

If some are wondering why that specific order... that order would make a lot of sense when reading a .zip archive from a CD or even from a HDD, so the AppleDouble file for a resource fork would be found right after the data fork... to avoid having to go back to the beginning of a CD just to find the AppleDouble file... since it's supposed to be part of the same file, but they just split it into data forks and resource forks on file systems that don't support resource forks and for archives.

Although the Archive Utility seems to also recognize the __MACOSX folder even if the whole __MACOSX folder with everything in it was just appended to the end of an archive (but it doesn't seem to recognize it if the __MACOSX folder with everything in it was written to the beginning of some archive before other files)... but that adding "your_folder" with everything in it first and then just appending the __MACOSX folder with everything in it to the archive does not seem fully compatible with the unar binary, which is used by different archivers.

At the moment, when you add the __MACOSX folder with 7zip for some folder, if you add it for a folder called "1", then 7zip arranges files inside the archive so that the folder "1" is written before the "__MACOSX" folder and the Archive Utility recognizes the __MACOSX folder in that case (but as I mentioned, other archivers could have issues if the whole __MACOSX folder is just appended to the end of an archive, instead of arranging files in a way I described earlier)... but if you add the __MACOSX folder for a folder called "your_folder", 7zip arranges files in a way that __MACOSX folder is written before "your_folder" and in that case even the Archive Utility just seems to ignore the __MACOSX folder.

BTW... Another way of adding AppleDouble files to archives without creating a __MACOSX folder is to add "._" AppleDouble file to the same folder after adding a file... so if you have "your_folder" and a files with file names like "file1", "file2" and "file3" inside with "._file1", "._file2" and "._file3" AppleDouble files for those files inside of that folder also, you add "file1", then "._file1" after it and then you could add "file2" and "._file2" and so on... that way of adding AppleDouble files is used for .tar and .cpio archives and it can also be used for .zip when creating a .zip archive from the Terminal.

make 7za -j -s

../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_createCCtx_internal’:
../../../../C/fast-lzma2/fl2_compress.c:149:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (unsigned u = 0; u < nbThreads; ++u)
^
../../../../C/fast-lzma2/fl2_compress.c:149:5: note: use option -std=c99 or -std=gnu99 to compile your code
../../../../C/fast-lzma2/fl2_compress.c:172:19: error: redefinition of ‘u’
for (unsigned u = 0; u < nbThreads; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c:149:19: note: previous definition of ‘u’ was here
for (unsigned u = 0; u < nbThreads; ++u)
^
../../../../C/fast-lzma2/fl2_compress.c:172:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (unsigned u = 0; u < nbThreads; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_freeCCtx’:
../../../../C/fast-lzma2/fl2_compress.c:208:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (unsigned u = 0; u < cctx->jobCount; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_initEncoders’:
../../../../C/fast-lzma2/fl2_compress.c:248:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for(unsigned u = 0; u < cctx->jobCount; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_compressCurBlock_blocking’:
../../../../C/fast-lzma2/fl2_compress.c:288:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t u = 1; u < nbThreads; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c:352:17: error: redefinition of ‘u’
for (size_t u = 0; u < nbThreads; ++u)
^
../../../../C/fast-lzma2/fl2_compress.c:288:17: note: previous definition of ‘u’ was here
for (size_t u = 1; u < nbThreads; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c:352:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t u = 0; u < nbThreads; ++u)
^
../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_compressBuffer’:
../../../../C/fast-lzma2/fl2_compress.c:512:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t u = 0; u < cctx->threadCount; ++u) {
^
../../../../C/fast-lzma2/fl2_compress.c: In function ‘FL2_remainingOutputSize’:
../../../../C/fast-lzma2/fl2_compress.c:1124:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t u = fcs->outThread; u < fcs->threadCount; ++u)
^
make[1]: *** [fl2_compress.o] Error 1
make[1]: *** Waiting for unfinished jobs....
../../../../C/fast-lzma2/fl2_pool.c: In function ‘FL2POOL_join’:
../../../../C/fast-lzma2/fl2_pool.c:131:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < ctx->numThreads; ++i)
^
../../../../C/fast-lzma2/fl2_pool.c:131:5: note: use option -std=c99 or -std=gnu99 to compile your code
make[1]: *** [fl2_pool.o] Error 1
In file included from ../../../../C/fast-lzma2/lzma2_enc.c:17:0:
../../../../C/fast-lzma2/range_enc.h: In function ‘RC_flush’:
../../../../C/fast-lzma2/range_enc.h:154:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (int i = 0; i < 5; ++i)
^
../../../../C/fast-lzma2/range_enc.h:154:5: note: use option -std=c99 or -std=gnu99 to compile your code
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_lengthStates_SetPrices’:
../../../../C/fast-lzma2/lzma2_enc.c:384:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < 8; i += 2) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_lengthStates_updatePrices’:
../../../../C/fast-lzma2/lzma2_enc.c:404:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos_state = 0; pos_state <= enc->pos_mask; pos_state++) {
^
../../../../C/fast-lzma2/lzma2_enc.c:435:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos_state = 1; pos_state <= enc->pos_mask; pos_state++)
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_encodeChunkFast’:
../../../../C/fast-lzma2/lzma2_enc.c:650:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t next = pos + 1; best_match.length < kMatchLenMax && next < uncompressed_end; ++next) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_optimalParse’:
../../../../C/fast-lzma2/lzma2_enc.c:1082:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t rep_index = 0; rep_index < kNumReps; ++rep_index) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_initMatchesPos0Best’:
../../../../C/fast-lzma2/lzma2_enc.c:1313:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (ptrdiff_t match_index = enc->match_count - 1; match_index >= start_match; --match_index) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_initOptimizerPos0’:
../../../../C/fast-lzma2/lzma2_enc.c:1362:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumReps; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1410:17: error: redefinition of ‘i’
for (size_t i = 0; i < kNumReps; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1362:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < kNumReps; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1410:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumReps; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_encodeOptimumSequence’:
../../../../C/fast-lzma2/lzma2_enc.c:1483:21: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t j = cur + 1; j <= len_end; j++) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1497:17: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t j = cur + 1; j <= end; j++) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_fillDistancesPrices’:
../../../../C/fast-lzma2/lzma2_enc.c:1579:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = kStartPosModelIndex / 2; i < kNumFullDistances / 2; i++) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1603:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (unsigned lps = 0; lps < kNumLenToPosStates; lps++) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1641:13: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 4; i < kNumFullDistances; i += 2) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_lengthStates_Reset’:
../../../../C/fast-lzma2/lzma2_enc.c:1703:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < (kNumPositionStatesMax << (kLenNumLowBits + 1)); ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1706:17: error: redefinition of ‘i’
for (size_t i = 0; i < kLenNumHighSymbols; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1703:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < (kNumPositionStatesMax << (kLenNumLowBits + 1)); ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1706:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kLenNumHighSymbols; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA_encoderStates_Reset’:
../../../../C/fast-lzma2/lzma2_enc.c:1716:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumReps; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1719:17: error: redefinition of ‘i’
for (size_t i = 0; i < kNumStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1716:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < kNumReps; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1719:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1720:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t j = 0; j < kNumPositionStatesMax; ++j) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1730:17: error: redefinition of ‘i’
for (size_t i = 0; i < num; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1719:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < kNumStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1730:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < num; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1733:17: error: redefinition of ‘i’
for (size_t i = 0; i < kNumLenToPosStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1730:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < num; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1733:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumLenToPosStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1735:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t j = 0; j < (1 << kNumPosSlotBits); ++j)
^
../../../../C/fast-lzma2/lzma2_enc.c:1738:17: error: redefinition of ‘i’
for (size_t i = 0; i < kNumFullDistances - kEndPosModelIndex; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1733:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < kNumLenToPosStates; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1738:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < kNumFullDistances - kEndPosModelIndex; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1744:17: error: redefinition of ‘i’
for (size_t i = 0; i < (1 << kNumAlignBits); ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1738:17: note: previous definition of ‘i’ was here
for (size_t i = 0; i < kNumFullDistances - kEndPosModelIndex; ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c:1744:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < (1 << kNumAlignBits); ++i)
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA2_getDictSizeProp’:
../../../../C/fast-lzma2/lzma2_enc.c:1751:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (BYTE bit = 11; bit < 32; ++bit) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA2_isChunkIncompressible’:
../../../../C/fast-lzma2/lzma2_enc.c:1840:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos = start; pos < end; ) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1867:4: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos = start; pos < end; ) {
^
../../../../C/fast-lzma2/lzma2_enc.c:1895:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos = start; pos < end; ++pos)
^
../../../../C/fast-lzma2/lzma2_enc.c:1898:9: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t i = 0; i < 256; ++i) {
^
../../../../C/fast-lzma2/lzma2_enc.c: In function ‘LZMA2_encode’:
../../../../C/fast-lzma2/lzma2_enc.c:1990:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
for (size_t pos = start; pos < block.end;) {
^
make[1]: *** [lzma2_enc.o] Error 1

make: *** [7za] Error 2

gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC)

symlinks contained inside tar can't decompress correctly.
I test p7zip 7za, tar can't decompress correctly & zip can decompress correctly.

I'm not sure how to compress to 7z with FastLZMA2. It seems to use LZMA2.

Also, for compression level of FastLZMA2, I wonder if Fast is best or I should use Normal or maybe Maximum or even Ultra? I'm looking for fastest decompression.

Hi, I would like to package this fork for voidlinux, however I've being queried about

What makes this fork authoritative? This is doubly relevant because the homepage is still p7zip.sourceforge.net, but that site does not appear to direct people to the new fork.

and I'm in no position to answer the question, would you mind shed some light on this?

tracking void-linux/void-packages#27953

time ./7za a -m0=FLZMA2 7b.7z /tmp/z.tar

7-Zip (a) [64] 17.02 : Copyright (c) 1999-2020 Igor Pavlov : 2017-08-28
p7zip Version 17.02 (locale=en_US.utf8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Scanning the drive:
1 file, 17643520 bytes (17 MiB)

Creating archive: 7b.7z

Items to compress: 1

Files read from disk: 1
Archive size: 4439670 bytes (4336 KiB)
Everything is Ok

real 0m29.067s
user 0m8.021s
sys 0m0.192s

time ./7za a -m0=FLZMA2 -mmt=4 7c.7z /tmp/z.tar

7-Zip (a) [64] 17.02 : Copyright (c) 1999-2020 Igor Pavlov : 2017-08-28
p7zip Version 17.02 (locale=en_US.utf8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Scanning the drive:
1 file, 17643520 bytes (17 MiB)

Creating archive: 7c.7z

Items to compress: 1

Files read from disk: 1
Archive size: 4439670 bytes (4336 KiB)
Everything is Ok

real 0m29.261s
user 0m8.060s
sys 0m0.201s

cp makefile.linux_amd64 makefile.machine
make -j 4 Client7z
output error is:

../../../../CPP/7zip/UI/Client7z/Client7z.cpp: In function ‘int main(int, const char**)’:
../../../../CPP/7zip/UI/Client7z/Client7z.cpp:936:58: error: invalid new-expression of abstract class type ‘CArchiveExtractCallback’
936 | CArchiveExtractCallback *extractCallbackSpec = new CArchiveExtractCallback;
| ^~~~~~~~~~~~~~~~~~~~~~~
../../../../CPP/7zip/UI/Client7z/Client7z.cpp:195:7: note: because the following virtual functions are pure within ‘CArchiveExtractCallback’:
195 | class CArchiveExtractCallback:
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../../../CPP/7zip/UI/Client7z/Client7z.cpp:25:
../../../../CPP/7zip/UI/Client7z/../../Archive/IArchive.h:178:16: note: ‘virtual bool IArchiveExtractCallback::SetFileSymLinkAttrib()’
178 | virtual bool SetFileSymLinkAttrib() x;
| ^~~~~~~~~~~~~~~~~~~~
../../../../CPP/7zip/UI/Client7z/../../Archive/IArchive.h:182:3: note: in expansion of macro ‘INTERFACE_IArchiveExtractCallback’
182 | INTERFACE_IArchiveExtractCallback(PURE)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [makefile.list:48: Client7z.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/test/p7zip_17.02/CPP/7zip/UI/Client7z'
make: *** [makefile:25: Client7z] Error 2

and LZHAM custom codec plugin is missing.

https://nvd.nist.gov/vuln/detail/CVE-2017-17969

Heap-based buffer overflow in the NCompress::NShrink::CDecoder::CodeReal method in 7-Zip before 18.00 and p7zip allows remote attackers to cause a denial of service (out-of-bounds write) or potentially execute arbitrary code via a crafted ZIP archive.-

https://github.com/inikep/lz5/ redirects to https://github.com/inikep/lizard

So Lizard is LZ5 with bugfixes ( inikep/lizard#28 )

It really doesn't make sense to keep LZ5, unless it's a version incompatible with Lizard...

If Lizard can decompress LZ5, then the lz5 compressor and decompressor should be removed, otherwise only the lz5 compressor should be removed,

But reading a bit more: Lizard = LZ5 = LZ4 ??? Apparently LZ4 is the format and LZ5/Lizard is just an improved compressor. Hmmm

I got the following error compiling p7zip 17.02 in Linux Mint 20:

mkdir -p bin/Codecs
make -C CPP/7zip/Bundles/Format7zFree all
make[1]: Entering directory '/home/mizuki/Downloads/p7zip/CPP/7zip/Bundles/Format7zFree'
gcc -c -I. -I../../../../C -I../../../../CPP/myWindows -I../../../../CPP/include_windows -I../../../../CPP -O2 -s -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -fPIC -DRegisterArc=DllRegisterArc -DRegisterCodec=DllRegisterCodec -DEXTERNAL_CODECS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_REENTRANT -DENV_UNIX -DBREAK_HANDLER -DUNICODE -D_UNICODE -DUNIX_USE_WIN_FILE -DZSTD_MULTITHREAD -DNO_XXHASH -DFL2_7ZIP_BUILD   ../../../../C/7zBuf2.c
../../../../C/7zBuf2.c:6:10: fatal error: string.h: No such file or directory
    6 | #include <string.h>
      |          ^~~~~~~~~~
compilation terminated.
make[1]: *** [makefile.list:339: 7zBuf2.o] Error 1
make[1]: Leaving directory '/home/mizuki/Downloads/p7zip/CPP/7zip/Bundles/Format7zFree'
make: *** [makefile:44: common7z] Error 2```

Stumbled upon this warning under Alpine which uses musl instead of glibc:

gcc -c -I. -I../../../../C -I../../../../CPP/myWindows -I../../../../CPP/include_windows -I../../../../CPP -O -s -pipe -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DNDEBUG -D_REENTRANT -DENV_UNIX -D_7ZIP_LARGE_PAGES -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_REENTRANT -DENV_UNIX -DBREAK_HANDLER -DUNICODE -D_UNICODE -DUNIX_USE_WIN_FILE -DZSTD_MULTITHREAD -DNO_XXHASH -DFL2_7ZIP_BUILD ../../../../C/Threads.c ../../../../C/Threads.c:15: warning: "PTHREAD_MUTEX_ERRORCHECK" redefined 15 | #define PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_ERRORCHECK_NP | In file included from ../../../../C/Threads.h:14, from ../../../../C/Threads.c:3: /usr/include/pthread.h:39: note: this is the location of the previous definition 39 | #define PTHREAD_MUTEX_ERRORCHECK 2

musl appears to not support for PTHREAD_MUTEX_ERRORCHECK_NP:
https://git.musl-libc.org/cgit/musl/tree/include/pthread.h

(not really a C programmer myself, but) The following quick'n'dirty 'fix' in Threads.c, appears to have taken care of such:

#if defined(__linux__) && defined(__GLIBC__)
#define PTHREAD_MUTEX_ERRORCHECK PTHREAD_MUTEX_ERRORCHECK_NP
#endif

All the best

I tested the FLZMA2 method and compared the Linux and Windows versions, but on Linux is same than LZMA2.

Linux -m0=lzma2 -mx5 -md24m -ms4g -mqs      0:49    58328960 bytes
Linux -m0=flzma2 -mx5 -md24m -ms4g -mqs     0:49    58328957 bytes
Windows -m0=lzma2 -mx5 -md24m -ms4g -mqs    1:18    58259752 bytes
Windows -m0=flzma2 -mx5 -md24m -ms4g -mqs   0:24    59998802 bytes

Linux HW: Intel i7 4790K,RAM 32 GB
Windows HW: Intel i7 Q720, RAM 8 GB

Windows SW: https://github.com/mcmilk/7-Zip-zstd

Any solution?

https://nvd.nist.gov/vuln/detail/CVE-2018-5996

Insufficient exception handling in the method NCompress::NRar3::CDecoder::Code of 7-Zip before 18.00 and p7zip can lead to multiple memory corruptions within the PPMd code, allows remote attackers to cause a denial of service (segmentation fault) or execute arbitrary code via a crafted RAR archive.

https://github.com/NEWPLAN/SMx/tree/master/SM4/Linux
https://github.com/guanzhi/GmSSL/tree/master/crypto/sms4
https://github.com/openssl/openssl/tree/master/crypto/sm4

Add support to open squashfs file with zstd compression.

Thanks.

Similar problems such as #39

symlinks contained inside squashfs can't decompress correctly.

Thanks.

Hello,
At work, I use a lot of 7z files with zstd so thank you for creating this fork.
When you have time, please update zstd codec to the latest 1.4.5 which it improves a little the compression ratio.

Reported by @tonurics on Arch Linux bugtracker (FS#69253).

To clarify, assume you have zip file called "foo.zip" containing one item: "readme.txt"
Taking the same file above and instead using switch e [to extract to the working directory, i.e 7z e foo.zip], one of two things will happen [depending on the zip file]: sometimes 7z creates a file named "IBM437.so" with the contents of "readme.txt".

Seeing IBM437 makes me think of c104127...

Note: Arch Linux already switched to your p7zip fork and is providing 17.03 in the official repository.

https://sourceforge.net/p/p7zip/bugs/187/#816e

Original discussion: mate-desktop/engrampa#5

11111

cp makefile.linux_amd64 makefile.machine
make -j 4 test_7zr

/usr/bin/ld: XzHandler.o: in function NArchive::NXz::CHandler::Close()': XzHandler.cpp:(.text+0x132): undefined reference to NCompress::NXz::CStatInfo::Clear()'
/usr/bin/ld: XzHandler.o: in function NArchive::NXz::CHandler::Extract(unsigned int const*, unsigned int, int, IArchiveExtractCallback*)': XzHandler.cpp:(.text+0x8b3): undefined reference to NCompress::NXz::CStatInfo::Clear()'
/usr/bin/ld: XzHandler.cpp:(.text+0x8bd): undefined reference to NCompress::NXz::CXzUnpackerCPP::CXzUnpackerCPP()' /usr/bin/ld: XzHandler.cpp:(.text+0x8ed): undefined reference to NCompress::NXz::CDecoder::Decode(ISequentialInStream*, ISequentialOutStream*, unsigned long long const*, bool, ICompressProgressInfo*)'
/usr/bin/ld: XzHandler.cpp:(.text+0x941): undefined reference to NCompress::NXz::CDecoder::Get_Extract_OperationResult() const' /usr/bin/ld: XzHandler.cpp:(.text+0x973): undefined reference to NCompress::NXz::CXzUnpackerCPP::~CXzUnpackerCPP()'
/usr/bin/ld: XzHandler.cpp:(.text+0xa2e): undefined reference to NCompress::NXz::CXzUnpackerCPP::~CXzUnpackerCPP()' /usr/bin/ld: XzHandler.o: in function NArchive::NXz::CHandler::UpdateItems(ISequentialOutStream*, unsigned int, IArchiveUpdateCallback*)':
XzHandler.cpp:(.text+0xbdb): undefined reference to NCompress::NXz::CEncoder::CEncoder()' /usr/bin/ld: XzHandler.cpp:(.text+0xc42): undefined reference to NCompress::NXz::CEncoder::SetCheckSize(unsigned int)'
/usr/bin/ld: XzHandler.cpp:(.text+0xd37): undefined reference to NCompress::NXz::CEncoder::SetCoderProp(unsigned int, tagPROPVARIANT const&)' /usr/bin/ld: XzHandler.o: in function NArchive::NXz::CHandler::CHandler()':
XzHandler.cpp:(.text+0x2668): undefined reference to NCompress::NXz::CStatInfo::Clear()' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::TranslateError(unsigned long)':
Lzma2Encoder.cpp:(.text+0x1a0): undefined reference to FL2_getErrorCode' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::~FastLzma2()':
Lzma2Encoder.cpp:(.text+0x31c): undefined reference to FL2_freeCCtx' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::SetCoderProperties(unsigned int const*, tagPROPVARIANT const*, unsigned int)':
Lzma2Encoder.cpp:(.text+0x40c): undefined reference to FL2_CCtx_setParameter' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x41e): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x466): undefined reference to FL2_CCtx_setParameter' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x46e): undefined reference to FL2_isError'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x531): undefined reference to FL2_CCtx_setParameter' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x539): undefined reference to FL2_isError'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x554): undefined reference to FL2_CCtx_setParameter' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x562): undefined reference to FL2_setCStreamTimeout'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x582): undefined reference to FL2_createCStreamMt' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x5a8): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x5bb): undefined reference to FL2_CCtx_getParameter' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x5d2): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x5da): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x5fd): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x605): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x627): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x62f): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x652): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x65a): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x67d): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x685): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x6a8): undefined reference to FL2_CCtx_setParameter'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x6b0): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::GetDictSize() const':
Lzma2Encoder.cpp:(.text+0x729): undefined reference to FL2_CCtx_getParameter' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::Begin()':
Lzma2Encoder.cpp:(.text+0x7aa): undefined reference to FL2_initCStream' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x7b5): undefined reference to FL2_isError'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x7d4): undefined reference to FL2_getDictionaryBuffer' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x7df): undefined reference to FL2_isError'
/usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::UpdateProgress(ICompressProgressInfo*)': Lzma2Encoder.cpp:(.text+0x831): undefined reference to FL2_getCStreamProgress'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x862): undefined reference to FL2_cancelCStream' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::WaitAndReport(unsigned long&, ICompressProgressInfo*)':
Lzma2Encoder.cpp:(.text+0x87f): undefined reference to FL2_isTimedOut' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x89b): undefined reference to FL2_waitCStream'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x8ab): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::WriteBuffers(ISequentialOutStream*)':
Lzma2Encoder.cpp:(.text+0x8e4): undefined reference to FL2_getNextCompressedBuffer' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x8ef): undefined reference to FL2_isTimedOut'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x8fb): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::AddByteCount(unsigned long, ISequentialOutStream*, ICompressProgressInfo*)':
Lzma2Encoder.cpp:(.text+0x975): undefined reference to FL2_updateDictionary' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x9b4): undefined reference to FL2_getDictionaryBuffer'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x9c3): undefined reference to FL2_isTimedOut' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0x9e1): undefined reference to FL2_getDictionaryBuffer'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0x9f5): undefined reference to FL2_isError' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::End(ISequentialOutStream*, ICompressProgressInfo*)':
Lzma2Encoder.cpp:(.text+0xa42): undefined reference to FL2_updateDictionary' /usr/bin/ld: Lzma2Encoder.cpp:(.text+0xa68): undefined reference to FL2_endStream'
/usr/bin/ld: Lzma2Encoder.cpp:(.text+0xaa8): undefined reference to FL2_endStream' /usr/bin/ld: Lzma2Encoder.o: in function NCompress::NLzma2::CFastEncoder::FastLzma2::Cancel()':
Lzma2Encoder.cpp:(.text+0xae4): undefined reference to `FL2_cancelCStream'
collect2: error: ld returned 1 exit status
make[1]: *** [../../../../makefile.glb:26: ../../../../bin/7zr] Error 1
make[1]: Leaving directory '/tmp/test/p7zip_17.02/CPP/7zip/Bundles/Alone7z'
make: *** [makefile:20: 7zr] Error 2

I find no install target provided in CMakeLists.txt. It seems that no reasons motioned in docs, dos there exist some particular reasons?

I myself add following instructions to CMakeLists.txt:

install(PROGRAMS ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/7z_ ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/7za ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/7zr DESTINATION bin)

This fork's "17.00" and "17.01" releases are not based on 7-Zip 17.00/17.01.
To avoid confusion, please consider naming the release to something like "16.02.1" to indicate the actual 7-Zip version that the release is based on.
Using another naming scheme, such as using the release date as the version name (e.g. version 2020.05.13), would also be a good idea.

https://nvd.nist.gov/vuln/detail/CVE-2016-9296

A null pointer dereference bug affects the 16.02 and many old versions of p7zip. A lack of null pointer check for the variable folders.PackPositions in function CInArchive::ReadAndDecodePackedStreams in CPP/7zip/Archive/7z/7zIn.cpp, as used in the 7z.so library and in 7z applications, will cause a crash and a denial of service when decoding malformed 7z files.

7z does not support -so but xz does, so the newer compression methods cannot be used for piping beyond -si. When transfering hundreds of GB's to a remote server, there is no need for a [temporary] local file to be created.

This is probably my mistake, I ask for help. I'm get InArchive pointer by Detach() and after Attach() this pointer, i'm can't get archive items, *_items address dumped to 0x00000003. Screenshots:
https://drive.google.com/file/d/1w5hTwJWWDx1mpv1nEAxIyF-FdOFOH_Qm/view?usp=sharing
https://drive.google.com/file/d/1wq2k_KF5akqBrCcPb3F4ulforG7alY0r/view?usp=sharing

...as it currently stands, kinda leaves a bit to be desired i think.
Example:
wget ftp.debian.org/debian/pool/main/p/p7zip/p
7zip-full_16.02+dfsg-8_amd64.deb

7z e p7zip-full_16.02+dfsg-8_amd64.deb
Extracts 'data.tar' only.

7z e p7zip-full_16.02+dfsg-8_amd64.deb -t*
Extracts data.tar.xz and control.tar.xz.

ar x p7zip-full_16.02+dfsg-8_amd64.deb
Extracts everything: data.tar.xz, control.tar.xz and debian-binary.

Digging around, there were quite a few similar threads / reports about this behavior in the past:
https://sourceforge.net/p/sevenzip/discussion/45797/thread/062118a8
https://sourceforge.net/p/sevenzip/bugs/1130/
https://sourceforge.net/p/sevenzip/bugs/1472/
https://sourceforge.net/p/p7zip/bugs/141/

Same as with people above, i'd personally think that's more convoluted than actually needed.
Someone does need to know in advance that 7z doesn't extract control.tar by default...or that deb is essentially an ar file.
At some point down the road, could this possibly get simplified,
ie. have 7z at least extract the control.tar by default,
more close to ar's behavior?

All the best

In p7zip v16.02 (original) and p7zip v17.01 I have these files:
/usr/lib64/p7zip/Lzham.so
/usr/lib64/p7zip/Codecs/Lzham.so
In p7zip v17.02 the error below appears and both files are missing.

../../../../CPP/7zip/UI/Client7z/Client7z.cpp: In function ‘int main(int, const char**)’:
../../../../CPP/7zip/UI/Client7z/Client7z.cpp:936:58: error: invalid new-expression of abstract class type ‘CArchiveExtractCallback’
936 | CArchiveExtractCallback *extractCallbackSpec = new CArchiveExtractCallback;
| ^~~~~~~~~~~~~~~~~~~~~~~
../../../../CPP/7zip/UI/Client7z/Client7z.cpp:195:7: note: because the following virtual functions are pure within ‘CArchiveExtractCallback’:
195 | class CArchiveExtractCallback:
| ^~~~~~~~~~~~~~~~~~~~~~~
In file included from ../../../../CPP/7zip/UI/Client7z/Client7z.cpp:25:
../../../../CPP/7zip/UI/Client7z/../../Archive/IArchive.h:178:16: note: ‘virtual bool IArchiveExtractCallback::SetFileSymLinkAttrib()’
178 | virtual bool SetFileSymLinkAttrib() x;
| ^~~~~~~~~~~~~~~~~~~~
../../../../CPP/7zip/UI/Client7z/../../Archive/IArchive.h:182:3: note: in expansion of macro ‘INTERFACE_IArchiveExtractCallback’
182 | INTERFACE_IArchiveExtractCallback(PURE)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [makefile.list:48: Client7z.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/tmp/test/p7zip_17.02/CPP/7zip/UI/Client7z'
make: *** [makefile:25: Client7z] Error 2

huawei@0584c8621b15 /opt/buildtools/p7zip-17.02/bin]$7za -x /home/huawei/CentOS-7-x86_64-DVD-1804.iso

Command Line Error:
Too short switch:
-x
[huawei@0584c8621b15 /opt/buildtools/p7zip-17.02/bin]$7za x /home/huawei/CentOS-7-x86_64-DVD-1804.iso

7-Zip (a) [64] 17.02 : Copyright (c) 1999-2020 Igor Pavlov : 2017-08-28
p7zip Version 17.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Scanning the drive for archives:
1 file, 4470079488 bytes (4263 MiB)

Extracting archive: /home/huawei/CentOS-7-x86_64-DVD-1804.iso
ERROR: /home/huawei/CentOS-7-x86_64-DVD-1804.iso
Can not open the file as archive

Can't open as archive: 1
Files: 0
Size: 0
Compressed: 0

\\\

[huawei@0584c8621b15 /home/huawei]$7za x SLE-12-SP5-Server-DVD-x86_64-GM-DVD1.iso

7-Zip (a) [64] 17.02 : Copyright (c) 1999-2020 Igor Pavlov : 2017-08-28
p7zip Version 17.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Scanning the drive for archives:
1 file, 4098883584 bytes (3909 MiB)

Extracting archive: SLE-12-SP5-Server-DVD-x86_64-GM-DVD1.iso
ERROR: SLE-12-SP5-Server-DVD-x86_64-GM-DVD1.iso
Can not open the file as archive

Can't open as archive: 1
Files: 0
Size: 0
Compressed: 0

The precompiled binaries do not work under Sierra

It is showing an error "dyld: Symbol not found: ____chkstk_darwin"

When you compile on Sierra, it does not show such an error

Most people use p7zip provided by the repo and we should not mess with the main program files.
Due to this reason, the only viable solution is to make ZSTD as "additional codecs", like the RAR one.

This is great, thanks for forking and updating the p7zip sourceforge repo!

Just wondering if a new release tag is required, you've noted v19.00 in jinfeihan57@6106df2, but it seems that 17.03 is the latest tagged release.

I also wonder if a refresh using the 7-zip 21.01 release source would be useful, or possible? It seems this was updated on 10th March 2021, so should be up-to-date

Test file can be found in upstream 7-Zip discussion thread.

p7zip 17.03 gives a "Headers Error" warning when decompressing the test file.

Despite the warning, it seems that the file can be extracted successfully.

Original p7zip 16.02 does not have this problem.
libzip and bsdtar returns no warning / error for the test file.

Lzma2 and FlzMA2 have the same compression results. Two algorithm Settings, the actual call is the same algorithm.

A while back there was a crypto init issue with 7z.
Has that problem been fixed in this fork?

See the original postings here:
https://sourceforge.net/p/sevenzip/discussion/45797/thread/6f7607738c/
and
https://twitter.com/3lbios/status/1087848040583626753

I looked at your source code and the 7zip 1900 source code and did a comparison between the two RandGen.cpp files.
The three files are attached.
The code seems to have been extended a bit and there now also seems to be a 1000 cycles init while-loop added among other things, can you please insert these corrections ? Thanks.

diff.zip

Hi,
anyone get segfault while extracting a .xz with method=LZMA2:26 CRC64
Extracts fine with xz v.5.2.5..

Howdy,
It's possible this is a Haiku side issue, but I got the following build error trying to compile it today.
Screenshot
I see there is a make file already for Haiku in the directory, do I need to do anything with it?
Complete newb at this.

Git clone as of 7/11/2020 on Haiku R1 Nightly (7/11/2020).

Obviously this is a corner case, but if open a PPTX file with 7zip in windows, extract the contents to an empty folder and create a zip of the contents, I can get a zip file that after renaming it to pptx, it still opens perfectly in powerpoint. But with p7zip, the same isn't true with the same settings.

As long as I stick to Deflate, 7zip produces something that opens fine in PowerPoint after renaming it to a pptx file.

But with p7zip with the same settings (Deflate, ultra/-mx=9, word size 258/-mfb=258), the resulting pptx will invariably open but with error popups that the file needs repairing with followed by a complaint that there's content missing.

I'll upload a minimal reproducing file when I work next in case it helps.

Homebrew recently updated 7z to p7zip Version 17.03, and now it fails to extract XIP files which have worked flawlessly with the previous version.

Full output for 7z e Xcode_12.4.xip:

7-Zip [64] 17.03 : Copyright (c) 1999-2020 Igor Pavlov : 2017-08-28
p7zip Version 17.03 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,4 CPUs x64)

Scanning the drive for archives:
1 file, 11655535601 bytes (11 GiB)

Extracting archive: Xcode_12.4.xip
         
Content
ERRORS:
There are data after the end of archive

--
Path = Xcode_12.4.xip
Type = Xar
Physical Size = 11655535601
Headers Size = 3973
----
Path = Content
Size = 11655531068
Packed Size = 11655531068
Modified = 2021-01-09 01:51:35
Created = 2021-01-09 01:51:35
Accessed = 2021-01-09 01:25:24
Mode = -rw-r--r--
User = root
Group = wheel
Method = octet-stream
--
Path = Content
Type = xz
ERRORS:
There are data after the end of archive
Offset = 28
Physical Size = 3466672
Tail Size = 11652064368
Method = LZMA2:23
Streams = 1
Blocks = 1
Characteristics = BlockPackSize BlockUnpackSize

ERROR: There are some data after the end of the payload data : Content~

Sub items Errors: 1

Archives with Errors: 1

Open Errors: 1

Sub items Errors: 1

The file can be downloaded from https://developer.apple.com/download/more/ ; I sadly don't have another test file 😕

This happens on all machines I tested on, so it’s not caused by faulty hardware.

Aside from this error, there is no documentation whatsoever on FLZMA2 support, i.e. how to use it. Setting m0=flmza2 seems to work, but there are no speed or memory usage differences at all.

During compilation on Mac x64 gcc, there are a couple of clang “linker” input unused command line arguments for core foundation in the FLZMA2 part.