Brand new branch (63)
This new release introduces numerous changes, making it a proper new branch.
As is well known, many modifications typically correspond to many new "features"... ahem... bugs, but the new features are very interesting.
New compile-time define -DOPEN
It's now possible to create a version called zpaqfranz-open, completely based on code free from binary portions.
This is designed for environments where security is paramount.
https://github.com/fcorbelli/zpaqfranz/wiki/Security:-open-software
You can achieve a similar result by simply running:
sed -i "/NOSFTPSTART/,/NOSFTPEND/d" zpaqfranz-open.cpp-keyfile Support
It's now possible to complement the traditional password encryption method (-key something) with the use of a keyfile. This is a file (between 4KB and 50MB) whose hash can be used as an additional key.
Let's proceed step by step:
First, you need to identify a "good" file, one that has sufficiently good entropy.
To do this, you need to verify if it's good enough using the work keyfile command as in the example:
zpaqfranz work keyfile zpaqfranz.cpp
zpaqfranz v63.1p-JIT,SFTP-L,HW BLK3,SHA1/2,4,SFX64 55.1,(2025-08-13)
Entropy: 5.7211 bit/byte : Not suitable — entropy too low, choose a better one
0.015s (00:00:00,512) (with errors)
In this case, the zpaqfranz.cpp file is not good "enough".
What is a "good key file"?
It depends.
Generally, I suggest using a JPG image which, given its storage format, generally has very high entropy and is not easy to replicate exactly (cutted a very long story short)
Here's an example:
C:\zpaqfranz>zpaqfranz work keyfile 01.jpg
zpaqfranz v63.1p-JIT,SFTP-L,HW BLK3,SHA1/2,4,SFX64 55.1,(2025-08-13)
Entropy: 7.7894 bit/byte : Suitable for cryptography
encoded: 5gL9VGz7UyD1nZ8ffPWvGhNM1dm5tKqG38nmkW4L93f7hRFa6xp7KFsU13KWodyDgujhEFSXUPXPdoGs1Lou2kC1
<<01.jpg>>
|01 5: FIVE |19 W: WHISKEY UP|37 k: kilo |55 s: sierra |73 U: UNIFORM UP
|02 g: golf |20 v: victor |38 W: WHISKEY UP|56 U: UNIFORM UP|74 P: PAPA UP
|03 L: LIMA UP|21 G: GOLF UP|39 4: FOUR |57 1: ONE |75 X: XRAY UP
|04 9: NINE |22 h: hotel |40 L: LIMA UP|58 3: THREE |76 P: PAPA UP
|05 V: VICTOR UP|23 N: NOVEMBER UP|41 9: NINE |59 K: KILO UP|77 d: delta
|06 G: GOLF UP|24 M: MIKE UP|42 3: THREE |60 W: WHISKEY UP|78 o: oscar
|07 z: zulu |25 1: ONE |43 f: foxtrot |61 o: oscar |79 G: GOLF UP
|08 7: SEVEN |26 d: delta |44 7: SEVEN |62 d: delta |80 s: sierra
|09 U: UNIFORM UP|27 m: mike |45 h: hotel |63 y: yankee |81 1: ONE
|10 y: yankee |28 5: FIVE |46 R: ROMEO UP|64 D: DELTA UP|82 L: LIMA UP
|11 D: DELTA UP|29 t: tango |47 F: FOXTROT UP|65 g: golf |83 o: oscar
|12 1: ONE |30 K: KILO UP|48 a: alpha |66 u: uniform |84 u: uniform
|13 n: november |31 q: quebec |49 6: SIX |67 j: juliet |85 2: TWO
|14 Z: ZULU UP|32 G: GOLF UP|50 x: xray |68 h: hotel |86 k: kilo
|15 8: EIGHT |33 3: THREE |51 p: papa |69 E: ECHO UP|87 C: CHARLIE UP
|16 f: foxtrot |34 8: EIGHT |52 7: SEVEN |70 F: FOXTROT UP|88 1: ONE
|17 f: foxtrot |35 n: november |53 K: KILO UP|71 S: SIERRA UP
|18 P: PAPA UP|36 m: mike |54 F: FOXTROT UP|72 X: XRAY UP
5gL9 VGz7 UyD1 nZ8f fPWv GhNM 1dm5 tKqG 38nm kW4L
93f7 hRFa 6xp7 KFsU 13KW odyD gujh EFSX UPXP doGs 1Lou 2kC1
THIS KEY IS CRITICAL. Guard it. Losing it means losing your data.
PRIMARY : Print on paper. Store safely offline.
SECONDARY : Save to secure USB drive.
LAST RESORT: Photograph with extreme caution. Avoid cloud auto-upload!
Crucial KEY data copied on clipboard. Please safekeeping!
0.047s (00:00:00,864) (all OK)
If you use a keyfile (by adding -keyfile filename to the zpaqfranz command line), you risk, of course, losing it.
What happens if you lose the file?
You lose everything, because it's like forgetting the password.
Therefore, a "smart" way is to note down the corresponding recovery code, which zpaqfranz shows for this purpose. On Windows, this information is also copied to the clipboard; you can paste it into notepad, for example, or wherever you prefer.
I recommend PRINTING ON PAPER (or copying by hand, even better, but it's quite long) the key code, so you can handle the case where you lose the keyfile.
Obviously, this is not mandatory, it's just your business.
The preservation mechanisms (in order of security) are:
- Copy it by hand, with paper and pen. This is the absolutely safest method
- Print it on paper and store it away
- Save it on a USB drive (or more than one) that you will keep secure
- Last possibility: photograph it with your phone. This is not recommended, as there are MANY automatic backup systems that could upload your key to the cloud without your knowledge
Finally, remember: also use a password. The combination of key+keyfile makes a brute force attack very difficult.
Main Help Information Redesigned
Running zpaqfranz without parameters now shows logically organized help:
zpaqfranz v63.1p-JIT,SFTP-L,HW BLK3,SHA1/2,4,SFX64 55.1,(2025-08-13)
Top tier archiver w/dedup & HW SHA1/2 (C) by Franco Corbelli
Help : zpaqfranz h <command> (single) zpaqfranz h h (full)
Core : a, e, l, x
Backup : backup, g, mysqldump, q
Restore : ntfs, w
Info/list: dirsize, drive, fzf, i, ls, pakka, tui
Test : p, sync, t, testbackup
Cloud : cloud, download, sftp, ssh
File : 1on1, c, cp, d, dir, find, hash, n, r, rd, s, sum
Admin : ads, autotest, b, collision, consolidate, crop, dump, k, m, password, redu, trim, update, upgrade
Utils : checkpassword, comparehex, count, f, isopen, last, last2, pause, rsync, sfx, utf, versum, work, z
Switches : zpaqfranz h main zpaqfranz h common zpaqfranz h franz
Update : zpaqfranz update -force
This facilitates requesting additional help, for example zpaqfranz h a to get help on the add command.
New SSH Command with sha1sum, md5sum, sha256sum Commands and Switches
It's now possible (lightly tested on *nix) to use the libssh library to remotely execute commands, which for now are hardcoded: -sha1deep, -md5deep, -sha256deep, comparing the results with a local folder.
The command can also be used with the cloud command.
Explanation:
zpaqfranz already performs a quick check between the local file and the one uploaded remotely. This uses the QUICK hash and is therefore executed in a handful of seconds. However, it's not a global, intensive verification and might not detect corruptions.
Using the new command instead, the remote server will calculate (for example) the md5 hashes of the files, and the local zpaqfranz will compare them with those present. This way, I can have near certainty that they are exactly identical.
Currently, md5, sha1, and sha256 are supported. In the future, there will also be more performant ones (e.g., XXH3).
During use, on Windows 64, zpaqfranz downloads the necessary DLL libraries from my site, placing them in the executable folder.
-franzhash in Hash Command
A scenario that can occur is having to compare the hash of a very large local file residing on a solid-state disk with a remote one that instead resides on a magnetic disk, or having terabyte+ files on solid-state to be checked.
This is the practice of cloud backups for virtual machines.
In this example, I'm calculating with 4 threads (-t4) and -sha256 the franzhash of the file j:\win11.zpaq:
Remember: -t4!
C:\zpaqfranz>zpaqfranz hash j:\win11.zpaq -franzhash -sha256 -t4
zpaqfranz v63.1p-JIT,SFTP-L,HW BLK3,SHA1/2,4,SFX64 55.1,(2025-08-13)
franzhash: parallel run 8.21 GB (NVMe/RAID of SSDs, multicore CPU)
100.00% ETA 00:00:00 8.21 GB @ 4.04 GB/s
franzhash:SHA-256:4:c:2204732550:5r^hm6S^Se1dOMq3AWN^0LIZb6o@7f6:E[f3A`NN0fV*]6SpPb1IO&T681b\3&!WU7RB$f1dj)W6T@D$
2.031s (00:00:02,4.00MB) (all OK)
The result I obtained is visible in the second-to-last line.
SHA-256:4:
Note: SHA-256 and 4 are indicated, i.e., the number of parts (fundamental information).
Now if I want to check this file hash (for example, by running the check on a remote server), I must use EXACTLY this information: sha256 and 4 parts, but enforcing -frugal.
This will recalculate the hash but without using multithreading (therefore for magnetic disks. On solid state, just do not use -frugal)
Example:
zpaqfranz hash j:\win11.zpaq -franzhash -sha256 -t4 -frugal -terse
This is an extremely specialized topic. Let's say it's to maximize hash checking speed for both magnetic and solid-state disks.
By using powerful CPUs (multicore), hardware acceleration (AMD), and fast storage devices (NVMe Gen 5), it's not uncommon to reach real-world performance in the 5–8 GB/s range.
Clearly, this is not a cryptographically robust test like the standard sequential calculation, but it can boost performance by a factor of 4 or more — which makes a real difference when dealing with huge files (in the multi-terabyte range).
Work in progress
Help Info Reworked
Help management is being redesigned, both from an aesthetic and content perspective. It's very long and heavy work, but I work on it in my free time.
Win64: Virtual Memory "Supercache" Mechanism
The zpaq format inherently provides that output is random, meaning that archives, during the extraction phase, are read sequentially, but decompressed files are written (generally) NOT sequentially, but with head seeks.
This is not a problem using solid-state units (SSD/NVMe), but it can become one for magnetic disks, such as slow external USB units.
zpaqfranz already has the -ramdisk switch, which operates using the computer's RAM as a buffer to decompress files and then write them sequentially to output.
Memory usage is high and, furthermore, did not allow extraction of files larger than available RAM, not even with the w command (piecewise extraction).
In short, to understand, if your computer has 128GB of RAM, it cannot extract a 250GB file this way.
Now instead, if you configure multiple Windows paging files on solid-state units, you can use them to expand RAM (actually virtual memory) for this purpose.
Example:
Suppose you have a zpaq archive containing a large file, say 250GB, while your PC has only 128GB of RAM and you want to extract it to a magnetic disk (USB, or a NAS, etc.).
If you have a solid-state unit, for example a 2TB NVMe mounted, you can create a fixed swap file (let's say) of 1TB on it.
Using the two switches -ramdisk -ramsize, during x (extraction), a 250GB vector (in the example) will be allocated that will end up partly in RAM and partly on the NVMe disk.
Therefore, the extraction phase will be relatively fast (about 800MB/s on my PC, but it obviously depends on the cases) and then will be written at maximum possible speed to the output device, sequentially.
This is a particular scenario, but it can sometimes happen.
By the way, using -ramdisk triggers a re-calculation of the initial file hashes to ensure that the ones loaded into the memory vector match the original ones.
pc_info() Function
There's a new function in b (benchmark) and autotest that shows computer information to get feedback on CPU functionality (particularly support for accelerated SHA1/2 machine code execution).
In the help message shown by zpaqfranz (when launched without parameters), it's now indicated more clearly.
For example:
Top tier archiver w/dedup & HW SHA1/2 (C) by Franco Corbelli
clearly shows that acceleration is active, while in this case it's not:
Top tier archiver w/dedup (C) by Franco Corbelli
-checksize X Switch in a (add)
Fails if free space is less than X (e.g., 10GB or whatever you want). This serves to prevent storage space saturation and simultaneously launch a possible error handling script (exec_error) like "space is exhausted, fix it".
New checkspace Verb in work
Checks if there's enough space on one or more paths. In this example, we want at least 10GB to remain on C and 20GB on D, otherwise it calls a batch file:
zpaqfranz work checkspace c:\ 10g d:\ 20g -exec_error nospace_do_something.bat
Additional Improvements
- SFTP section improvements: Error corrections and output refinements
- Better ANCIENT handling
- *No findso for curl library on nix systems: Now the library is either magically found, or it fails and becomes your problem to install and configure it
- *Better information on how to install curl on nix systems that lack it: Not perfect, but helps beginner users
- Using -n X during add phase (with -stat) no longer shows more than X files: Limits verbosity, for example, to the first 100 modified files in an archive
- Limited testing on non-Windows systems: Please be patient and open issues on GitHub
Note
This release has not been extensively tested on non-Windows systems.
Please be patient and open issues on GitHub if you encounter problems.