update to latest 7z version, currently 23.01

[milahu]

7-zip.org says, the latest 7z version is 23.01
7-zip.org for linux provides the commend 7zz

how come that the latest p7zip version is 16.02?
is p7zip obsolete...?

the arch user repo has 7-zip-full which is 7z version 23.01
which installs a symlink from bin/7z to bin/7zz

debian has 7zip which is 7z version 23.01
which installs a symlink from bin/7z to bin/7zz

related

https://sourceforge.net/p/p7zip/bugs/226/#491d/d43e

Have you tried 7zip? It has Linux version now, v23 for that matter, so this may be better option than here. P7zip 17.xx is somewhat maintained here.

https://www.reddit.com/r/archlinux/comments/oxk1wi/why_is_7z_so_outdated/

p7zip 17.04 is released in April 2021, not 2017, according to its release page

note: https://github.com/jinfeihan57/p7zip is a fork of https://github.com/p7zip-project/p7zip

https://www.reddit.com/r/linux/comments/sose12/til_theres_a_fork_of_the_unmaintained_p7zip_port/

TIL there's a fork of the unmaintained p7zip port of 7-Zip

The p7zip port of 7-Zip is several releases behind and the project seems to be abandoned. I discovered this when a large archive failed to extract with Engrampa which uses it. It reported a "Headers Error" which is due to a compatibility problem between zip format implementations. 7-Zip has a fix but the port doesn't. But there's a fork on GitHub which is being actively maintained. Check it out.

I was able to extract the file using unzip.

Edit: As commenters pointed out, 7-Zip now has a Linux/Unix port as of mid-2021 so hopefully future development gets concentrated there, not that forks are necessarily bad.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260866

Hi folks,

p7zip is outdated unofficial port of 7-zip. Recently the author of 7-zip has
released sources for console version [1], which is now available in the ports
tree as archivers/7-zip. I mush say there is also an attempt to revive p7zip
development [2], however it lags behind original 7-zip and seems unlikely to
catch up in near future. Since your ports use p7zip I encourage you to check
7-zip and probably switch your ports to it.

For now archivers/7-zip installs single binary 7zz to avoid conflict with
p7zip, but this can be changed, if we decide switch everything to
archivers/7-zip. Alternatively, we may adjust USE=7z to handle both 7-zip
and p7zip depending on user preference.

1. https://sourceforge.net/p/sevenzip/discussion/45797/thread/cec5e63147/
2. https://github.com/jinfeihan57/p7zip

https://sourceforge.net/p/p7zip/discussion/383043/thread/fa143cf2/

There was another developer that worked for all p7zip related things. And there are no any news or messages from that developer. That situation with p7zip update stall is not good. But I don't work with linux code myself. Maybe later I'll try to look it.

https://linuxhint.com/7zip-linux-command-line/

Variants of 7-Zip

Two variations of 7-Zip for Linux and macOS are released:

1. The p7zip which is a Linux version of 7-Zip that is created by a third party.
   The most recent version of p7zip is 16.02. That version is now obsolete.

2. The 7-Zip for Linux/macOS is a new package that has all the modifications from the most recent 7-Zip for Windows.

Remember that p7zip may be a better choice to implement the Linux-specific features than the latest version of 7-Zip for Linux.

https://bugs.gentoo.org/855503

Some linux distributions are starting to use https://github.com/jinfeihan57/p7zip as a new upstream, as the previous one seems to be dead.
I think it'd be a good idea to follow along.

---

By "some distributions" apparently I meant only Arch, so nevermind.

Apparently the full package of 7-zip now supports linux as well, but apparently it's incompatible enough to warrant a new package sadly.

---

Current version of p7zip in the portage is 16.02
It is likely subject of multiple CVE
https://www.cvedetails.com/vulnerability-list/vendor_id-9220/product_id-30936/7-zip-P7zip.html

---

To get an idea of what other distros are tracking:
https://repology.org/project/7zip/versions
and
https://repology.org/project/p7zip/versions

https://askubuntu.com/questions/1465853/difference-between-several-command-line-tools-provided-for-7-zip-compression-li

When I search for 7zip in Ubuntu 23.04 packages, I find several results.

For example, package p7zip-full contains the /usr/bin/7z executable, while package 7zip contains the /usr/bin/7zz executable.

Version of 7z (in p7zip-full) is:

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21

Version of 7zz (in 7zip) is:

7-Zip (z) 22.01 (x64) : Copyright (c) 1999-2022 Igor Pavlov : 2022-07-15

And they seem to provide similar functionality.

What is the difference between these two commands and why Ubuntu 23.04 provides several packages with different versions?

What is the recommended package to provide "7-Zip command-line" functionality (with the ability to save and restore UN*X permissions and other meta-file data)?

---

The p7zip package on Ubuntu and Debian is from a fork of 7zip that added POSIX compatibility (for execution) back when 7zip was Windows-only. It is unmaintained, not having seen a release since 2016 (though maybe some would argue that makes it extraordinarily stable). (Arch Linux apparently packages a fork of p7zip.) Its manpage has this warning:

DO NOT USE the 7-zip format for backup purpose on Linux/Unix because :

7-zip does not store the owner/group of the file.

It seems it does support permissions, but those are often not sufficient for a proper backup without the user/group information to go with them.

---

It seems that both 7z and 7zz store file permission, but not ownership as you mentioned. I am using 7z for personal backups (not system backups), so it is OK. I am still confused about the command name of 7zz and the reason of keeping both packages in Ubuntu (universe) repositories.

---

There's no particular reason to stop packaging p7zip since it's not broken in anyway, and since it provides the 7z command, 7zip would have to either conflict with it to use the same command name, or the respective maintainers would have to work together to set up the Debian alternatives system for it. I'm guessing the packager for 7zip just went for the easiest way out, which is to use a different name, allowing it to be coinstallable with pz7ip.

7z and 7zz produce different results

mkdir somedir
dd if=/dev/urandom count=1 of=somedir/somefile
dd if=/dev/urandom count=1 of=somedir/somefile2
dd if=/dev/urandom count=1 of=somedir/somefile-3
dd if=/dev/urandom count=1 of=somedir/.somefile

p7zip-17.05/bin/7z a test-p7zip-17.05.$(date +%s).7z somedir/
sleep 2
p7zip-17.05/bin/7z a test-p7zip-17.05.$(date +%s).7z somedir/
sleep 2

7zz-22.01/bin/7zz a test-7zip-22.01.$(date +%s).7z somedir/
sleep 2
7zz-22.01/bin/7zz a test-7zip-22.01.$(date +%s).7z somedir/
sleep 2

7zz-23.01/bin/7zz a test-7zip-23.01.$(date +%s).7z somedir/
sleep 2
7zz-23.01/bin/7zz a test-7zip-23.01.$(date +%s).7z somedir/

sha256sum *.7z

result: the *.7z files have different checksums between 7z and 7zz

[Cyberavater]

result: the *.7z files have different checksums between 7z and 7zz

Afaik, the checksums should be different, because the header also contains time. You should be able to verify it by using the exact same tool and the same file.

[milahu]

the header also contains time

no. when i change only the archive creation time (with sleep 2)
then the archive checksums are equal

when i touch a content file to change its file time (like touch somedir/somefile)
and then create a new archive, then the archive checksum changes

when everything else is equal, archives created with 7z and 7zz
differ in file size and about 0.5% of bytes

it would be interesting, why exactly these bytes are different...

$ du -b test-p7zip-17.05.1696022090.7z test-7zip-22.01.1696022170.7z 
25838   test-p7zip-17.05.1696022090.7z
25841   test-7zip-22.01.1696022170.7z

cat test-p7zip-17.05.1696022090.7z | xxd -p -c1 >test-p7zip-17.05.1696022090.7z.hex
cat test-7zip-22.01.1696022170.7z | xxd -p -c1 >test-7zip-22.01.1696022170.7z.hex
diff -u test-p7zip-17.05.1696022090.7z.hex test-7zip-22.01.1696022170.7z.hex

--- test-p7zip-17.05.1696022090.7z.hex
+++ test-7zip-22.01.1696022170.7z.hex
@@ -6,11 +6,11 @@
 1c
 00
 04
-f2
-b7
-7b
-0a
-aa
+1b
+70
+4a
+ca
+ad
 64
 00
 00
@@ -26,10 +26,10 @@
 00
 00
 00
-42
-36
-a3
-7d
+07
+3f
+79
+e1
 01
 63
 ff
@@ -25751,53 +25751,56 @@
 71
 4a
 b8
-66
-9b
+80
+39
+1e
 11
-c3
-2c
-cd
-fd
-a1
-dd
-54
-60
 bc
-d0
-33
-25
-33
-aa
-95
-9a
-50
-0a
-7d
-89
-e9
-78
+ba
+6d
+38
+c2
+d3
 a2
-f1
-b4
-b3
-d0
-fd
-1e
-c3
-c9
-de
-6f
-f3
+13
+41
+7e
+43
 25
+a3
+ea
+4a
+06
+53
+92
+00
+16
+59
 4b
-ff
-9a
-4e
-11
-c2
-08
+5f
+be
+80
+eb
+60
+64
+d0
+f7
+85
+79
+7e
+a1
+76
+1d
+df
+5a
+38
+69
+89
 7d
-f0
+75
+65
+54
+00
 00
 00
 17
@@ -25808,7 +25811,7 @@
 01
 09
 80
-a6
+a9
 00
 07
 0b
@@ -25830,9 +25833,9 @@
 66
 0a
 01
-ef
-d7
-f2
-4c
+bc
+97
+4b
+7e
 00
 00

surprising:

• chown 0:0 somedir/somefile has no effect with 7z and 7zz
• chmod 0755 somedir/somefile affects both 7z and 7zz

example:

$ md5sum *.7z

bd6e72620782f82732e9baaccf35eded  test-7zip-22.01.1696022812.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-22.01.1696022816.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-22.01.1696022817.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-22.01.1696022867.chown.7z
963cb9165a45764fe3292e9e8c55804c  test-7zip-22.01.1696022979.chmod.7z

bd6e72620782f82732e9baaccf35eded  test-7zip-23.01-7za.1696022824.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-23.01-7za.1696022827.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-23.01-7za.1696022829.7z
bd6e72620782f82732e9baaccf35eded  test-7zip-23.01-7za.1696022871.chown.7z
963cb9165a45764fe3292e9e8c55804c  test-7zip-23.01-7za.1696022990.chmod.7z

b23217c861ce849ec5eae0b5c96879d1  test-p7zip-17.05.1696022834.7z
b23217c861ce849ec5eae0b5c96879d1  test-p7zip-17.05.1696022837.7z
b23217c861ce849ec5eae0b5c96879d1  test-p7zip-17.05.1696022839.7z
b23217c861ce849ec5eae0b5c96879d1  test-p7zip-17.05.1696022874.chown.7z
94276534086d578c9fd51d67baaa4693  test-p7zip-17.05.1696022996.chmod.7z

[tansy]

And what's the problem?
As long as archives produced are correct then difference between versions doesn't count.

[milahu]

difference between versions doesn't count

yes, a difference does matter

it would be interesting, why exactly these bytes are different

the question is: can we replace p7zip/bin/7z with 7z/bin/7zz?
in other words: are p7zip and 7z fully compatible?
in other words: is 7z/bin/7zz a drop-in replacement for p7zip/bin/7z?

if the answer is yes, then linux distros can completely drop p7zip
and replace it with 7z, creating a symlink from 7z/bin/7zz to 7z/bin/7z

some arguments to keep p7zip were
"p7zip preserves ownership of files" (chown) or
"p7zip preserves permissions of files" (chmod) or
but 7z/bin/7zz seems to store ownership and permissions of files

so, are there other reasons to keep p7zip?

[tansy]

There is branch
p7zip22.00. You can make new, p7zip23.01 branch and they may merge it into project as https://github.com/p7zip-project/p7zip/tree/p7zip23.01.

Before you request a pull change source new lines from Dos to Unix. You can use this script. Remember to follower the instruction - first copy while directory into backup (like $ cp -r 7zip-23.01 7zip-23.01~) and then $ ./d2u-dir-1.sh <dir~> <dir>.

You may also use .gitattributes like here.

[eclipseo]

• Linux/macOS versions of 7-Zip: IUnknown interface in new code doesn't use
  virtual destructor that was used in previous 7-Zip and p7zip:
  // virtual ~IUnknown() {}
  So 7-Zip's dynamically linked shared libraries (codecs) are not compatible
  between new 7-Zip for Linux/macOS and old 7-Zip (and p7zip).

could that cause issues?

[tansy]

could that cause issues?

Yes, incompatibility of pre-v23 standalone plugins in Linux/MacOS.
It had nothing to do with current p7zip here, that is v17, and very likely uses linked in plugins, so they don't have this issue.

In general that move is somewhat strange as standalone plugins from versions prior to v23 don't work anymore.
Sure to the fact that almost no-one uses then this easy no-one really cares, but, in general it's an issue.

Supposedly it can be resolved by defining `Z7_USE_VIRTUAL_DESTRUCTOR_IN_IUNKNOWN' macro. This seems to work, but Changes in code are more profound and it cannot be driven down to one, simple macro.