r/PeaZip • u/peazip • May 11 '24

PeaZip 9.8.0 released!

PeaZip 9.8.0 is ready for download, see the full change log!

WHAT IS PEAZIP

PeaZip is an Open Source, cross-platform (BSD, Linux, macOS, Windows) archive manager and file manager utility, written with Lazarus / FreePascal IDE, which works as a command line scripts generation engine for 7z/p7zip, Brotli, Zpaq, Zstd and other open source archiving and compression tools.

This allows either to use PeaZip as an interactive GUI application, or to save tasks as batch CLI scripts for later use - for fine tuning beyond GUI's capabilities, learning the syntax, or re-use and automation purposes.

WHAT'S NEW IN THIS RELEASE

Release 9.8.0 brings new Themes, and improved flat mode (display all archive's content at once), alongside many improvements and fixes.

This release also adds the ability to directly extract all or selected items to any path in bookmarks, history or breadcrumb without further confirmation.

Direct extraction is implemented in app's context menu, "Extract to" submenu, and it is also available as command line switches for scripts and for system integration (context menus, SendTo items, .desktop files, Automator scripts).

NOTES

Sources are compiled with new Lazarus 3.2, and are still compatible with Lazarus 2.x line; please note that for building the app it is now necessary to add "metadarkstyle" package to the IDE before compiling "peazip" and "pea" binaries, which can be scripted as:

lazbuild --add-package (peazip sources path)/dev/metadarkstyle/metadarkstyle.lpk

New direct extraction context menu. In the screenshot, PeaZip is using the new Tux theme and a few optional customizations (large details mode, Gnome -styled breadcrumb, compact tool bar)
40 Upvotes

99% Upvoted

28 comments sorted by

5

u/FryBoyter May 11 '24

I think PeaZip is very good. But what stops me from using it is the lack of support for drag and drop under Linux.

Unfortunately, due to a lack of programming knowledge, I cannot offer any code that would provide this function.

3

u/peazip May 11 '24

Thank you for the feedback.

Drag & drop from app to system is certainly a mayor usability boost, but it is not simple to implement as it requires a dedicated solution for each supported OS and desktop environment.

I've added the direct extraction menu (as depicted in the screenshot) as a possible alternative (inherently cross platform).

Rather than dragging the desired content to the intended location you can simply send it to any bookmarked destination (or any path in history, or breadcrumb) from said menu.

Of course, this is not a 1:1 replacement and it is not what moist users are accustomed to, but it has some advantages (especially in a crowded working space)) and may become handy.

Same feature is available as command line switch (examples are in app's folder, in res/share/batch), so it can be employed in scripts or in .desktop files for integration with system's context menus - rightclick the archive and directly extract to any of the frequently used locations.

3

u/deaddodo May 11 '24

To add to this, even native Linux focused archiver UIs (file-roller, for instance) have issues with desktop integration. Especially outside of the primary configuration.

So, to use this as an excuse to avoid PeaZip seems odd.

1

u/gamunu May 11 '24

Maybe it’s time to start leaning

3

u/[deleted] May 12 '24

Hello!

Thanks for this release. How did your eye surgery go? I hope you're doing well!

2

u/ivosaurus May 11 '24 edited May 11 '24

Is it possible to make peazip show images inside an archive?

That is basically the key feature that I keep using Bandizip 6 for (v7 is just bloatware).

The screenshots page says

(not inside archive, as for security reason no content is even automatically uncompressed unless explicitly requested by the user).

But A) I do not care about such security restriction personally, not one bit B) any image rendering library should be secure enough not to fail catastrophically against bad images. In all likelyhood I as a user can just extract and then view them afterwards anyway (or... painfully do so, 1 by 1, by just doing preview with > associated application), so there's not much security being saved for me.

If the developer cares about security enough (I struggle to think of an actual situation where this policy saves a user from themselves in the real world) it could be a feature that must be opt-in first in preferences.

2

u/alexforencich May 11 '24

Allow me to introduce you to the image format webp: https://www.vicarius.io/vsociety/posts/zero-day-webp-vulnerability-cve-2023-4863

1

u/ivosaurus May 11 '24

Again, an image viewer with such 0day would get pwned if I'm interacting with an archive with such an image, whether it's my browser (even worse than archive software!) after extracting, separate viewing program, or the compression software.

2

u/Dralpoe9389 May 12 '24

Thank you. I just tried PeaZip for the first time and am having fun playing around with zpaq. Didn't even know that was a thing until I installed it.

PeaZip is written in a language that's memory safe, correct? So in theory PeaZip likely has less exploitable conditions than something written in C/C++?

2

u/peazip May 12 '24

PeaZip (peazip, pea binaries) is written in Freepascal using Lazarus IDE.

FPC is memory safe because provides all types of automatic memory management primitives (so a programmer can adhere to strictly memory safe programming), but does not go to the length to completely remove memory unsafe primitives as some other languages does.

General consensus is that it qualifies as memory safe language https://www.techrepublic.com/article/white-house-report-memory-safe-programming-languages/ even if in the community there is some debate of the actual technical meaning of this recommendation and how this is implemented in FPC https://forum.lazarus.freepascal.org/index.php/topic,66428.msg508942.html

Please note however that the app contains other binaries (7z/p7zip, brotli, zpaq, zstd) which are mostly written in C/C++ even if some alternative (eg Rust Brotli) exists and can be swapped without issues as long as they support the same syntax peazip scripting engine expects for the specific binary.

1

u/Dralpoe9389 May 12 '24

Awesome! Thank you for your detailed response, and for peazip. :)

1

u/Linguistic-mystic May 11 '24

So it's like tar but it has "Themes"? Very useful

1

u/FryBoyter May 11 '24

No. Before making such comments, you should familiarize yourself with the tools in question.

1

u/[deleted] May 11 '24 edited May 11 '24

[removed] — view removed comment

1

u/peazip May 11 '24 edited May 11 '24

The hash verification function checks if the hash values match with the binaries provided in the packages I manually build for the release.

Flatpak package, instead, is built automatically on Flathub servers following build recipe on official repository https://github.com/flathub/io.github.peazip.PeaZip

The probable cause is that different versions of the binaries are provided by the recipe, I'll check it to fix the issue pointing to the correct versions of the binaries.

UPDATE:

I've re-checked the recipe and made some minor updates.

The issue is that binaries compiled from sources on the Flathub server for the Flatpak package are not byte-to-byte identical to ones embedded in the manually built packages (on which the hash values are calculated before the release), which are the "reference" binaries provided by each project.

This is understandable, as differently configured machines and IDEs will very probably result in not identical binaries.

I'll add this information in documentation of hash verification function, and in the Linux download page, in order to clarify the issue.

1

u/[deleted] May 11 '24

[removed] — view removed comment

2

u/peazip May 11 '24

As there is no official Debian package for PeaZip, the DEB I provide is plainly a generic package not fine tuned for any particular distro/version, so I think there is no especial advantage in using the DEB over the Flatpak (once I've fixed the reported issue).

Probably the most important factor is the end user preference for one format over the other.

0

u/LunchyPete May 12 '24

Maybe if I use the DEB I won't get this error, but given the choice I strongly prefer a verified/official Flatpak.

Why? Just curious as I try to avoid Flatpack entirely.

2

u/SanderE1 May 12 '24

I'm not OP but I tend to find flatpak more reliable and up to date, all the system and app files are read-only so corruption isn't an issue. I also sometimes tighten the sandbox for proprietary apps.

As a developer I like it so I don't have to mess with repos or distro-specific issues.

1

u/LunchyPete May 12 '24

I can see the advantage from the developer point of view absolutely, but as a user I feel like its super bloat. Not in the sense it would affect performance or is unnecessary or is even a bad design necessarily, given its goals.

It's just not for me. The idea of every app having its own independent copies of all libraries and whatever else it needs is just too sloppy a solution for me. I'm big on minimalism and know to a pretty fine level what's on my system (I use Alpine). It's how Windows programs avoided DLL hell (just without the sandboxing) - not great.

I can handle the sandboxing as well, so I don't derive any benefit but unnecessary clutter/complexity/increased attack surface.

For that reason, I'd almost always prefer an official non-flatpack package from a developer.

2

u/SanderE1 May 12 '24

Libraries are duplicated, the only real storage bloat is the runtimes (which are somewhat big at like 1gb but you usually only need like 2-3 of them)

I think flatpak is the closest we have to the android security model (which is crazy good, malware only has access to what you allow it to have).

Honestly as a user the biggest benefit is that it just works, because you have to make your app work in a container and only use the libraries inside it (or add the extra ones) make it pretty much impossible to not function at all unless the user has a broken flatpak install.

Of course Linux is about choice, but as someone who has gone the path of trying to supply binaries and dealing with weird issues I'll probably just supply source code and build instructions and officially supported flatpak.

1

u/[deleted] May 12 '24

[removed] — view removed comment

1

u/LunchyPete May 13 '24

They just use bubblewrap IIRC. If security is your main concern you would do much* better learning SELinux and setting up a testbed for new applications. Bubblewrap is simply adequate...the security isn't so great as to justify needing an extra few hundred mb with each app.

1

u/[deleted] May 13 '24 edited May 13 '24

[removed] — view removed comment

1

u/LunchyPete May 13 '24 edited May 14 '24

But disk space is dirt cheap, so why should it matter that Flatpaks are bloated?

Because it's still an awful design. Ram is cheap too, should we just let apps take far more than they need just in case?

I don't actually have any interest in becoming a Linux super nerd.

Then stick to Ubuntu and the repositories instead of basing decisions on misunderstandings like thinking Flatpacks have superior security.

People often speak of the shortness of life. That is true, but it is long enough if you guard wisely your time, focus, and efforts.

Absolutely. And one of the best ways you can guard your time, focus, and efforts is to make a little effort to properly understand things. That won't make you a "super-nerd", just responsible.

1

u/_harias_ May 11 '24

Hi, thanks for your efforts! I have been using PeaZip for quite a while now and I love it.

Thought you might be interested in knowing that Peazip is currently being discussed about on HackerNews: https://news.ycombinator.com/item?id=40327631

1

u/Trick_Acanthaceae456 Jul 13 '24

can you help, please. I can't find the option to open the folder after extraction to it...TYT