Media "fullness" check
zpaq 7.15 does not throw errors when the free output space become too low
In this example the uncompressible file fill the available space, giving a corrupted zpaq archive but ending with "all OK". This is not good
zpaq64 a z:\ugo k:\2014.mp4 -summary 1
zpaq v7.15 journaling archiver, compiled Aug 17 2016
Creating z:/ugo.zpaq at offset 0 + 0
Adding 2256.846154 MB in 1 files -method 14 -threads 32 at 2021-12-20 16:43:19.
1 +added, 0 -removed.
0.000000 + (2256.846154 -> 2256.846154 -> 1415.975911) = 1415.975911 MB
8.875 seconds (all OK)
zpaqfranz 54.10 now compares bytes to be "theoretically" written with bytes that are reported as written
zpaqfranz a z:\ugo k:\2014.mp4
zpaqfranz v54.10d-experimental (HW BLAKE3), SFX64 v52.15, compiled Dec 20 2021
Integrity check type: XXHASH64+CRC-32 + CRC-32 by fragments
Creating z:/ugo.zpaq at offset 0 + 0
Adding 2.256.846.154 (2.10 GB) in 1 files at 2021-12-20 16:42:18
90.36% 00:00:00 ( 1.90 GB) -> ( 1.88 GB) of ( 2.10 GB) 243.09 MB/sec
1 +added, 0 -removed.
0 + (2.256.846.154 -> 2.256.846.154 -> 1.415.975.939) = 1.415.975.939
***********************************************************************************************
Something STRANGE happened. Archive seems corrupt. Media full?
WRITTEN BYTES 1.415.976.043
EXPECTED 2.257.392.747
***********************************************************************************************
10.250 seconds (000:00:10) (with errors)
The -debug switch show those errors
Here x (extract) says "all OK", but it is not
c:\nz\zpaq64 x macc.zpaq -to z:\muk -summary 1
zpaq v7.15 journaling archiver, compiled Aug 17 2016
macc_xxh3_G643p.zpaq: 115 versions, 1150 files, 10613081 fragments, 165389.322343 MB
Extracting 401005.451965 MB in 10 files -threads 32
435.360 seconds (all OK)
zpaqfranz 54.10+
zpaqfranz x macc.zpaq -to z:\kjn
zpaqfranz v54.10-experimental (HW BLAKE3), SFX64 v52.15, compiled Dec 20 2021
Archive seems encrypted (or corrupted)
Enter password :**************
macc.zpaq:
115 versions, 1.150 files, 10.613.081 fragments, 165.389.322.343 bytes (154.03 GB)
Extracting 401.005.451.965 bytes (373.46 GB) in 10 files -threads 32
99.66% 00:00:01 ( 372.21 GB) of ( 373.46 GB) 650.41 MB/sec
***********************************************************************************************
Something STRANGE happened. Archive seems corrupt. Media full?
WRITTEN BYTES 1.411.810.403
EXPECTED 400.082.097.403
***********************************************************************************************
588.141 seconds (000:09:48) (with errors)
New switch -checksum in command t (test)
Run hashtest after chunked-SHA1 against folders
The most reliable until p (paranoid) command and -paranoid switch
zpaqfranz a z:\1.zpaq c:\nz
zpaqfranz t z:\1.zpaq c:\nz -checksum
franzomips in command b (benchmark)
quick and dirty CPU speed comparison, either for single or multithread performances
zpaqfranz b
zpaqfranz b -all
franzomips are even worse than bogomips :)
A rating typically used for VPS and rented machines to get a rough idea of CPU performance (60s to not consume too much time). In the case of -all (multithreaded) run SHA-3 for all logical cores. You can use -tX to limit the number of tasks
BEWARE: no space, ex. -t4 for 4 threads
franzomips single thread index 1.093 (quick CPU check, raw 1.093)
Atom N2800 (phy) 4 268.60 %
Xeon E3 1245 V2 (vir) 4 45.27 %
i5-6200U (phy) 2 57.45 %
Xeon E5 2620 V4 (phy) 8 59.16 %
Xeon E5 2630 V4 (phy) 10 70.44 %
Xeon D-1541 (vir) 8 53.83 %
i5-3570 (phy) 4 36.98 %
i7-4790K (phy) 4 33.48 %
i7-8700K (phy) 6 32.56 %
i9-10900 (phy) 10 29.51 %
AMD-5950X (phy) 16 22.78 %
60.047 seconds (000:01:00) (all OK)
In the above example the single-core is ~ half speed of low-end Xeons