Windows 32/64 binary, 64 bit-HW accelerated, Intel/arm based

This branch introduces several new features, also new bugs, so it is up to you to use it with awareness

I understand that the "spiegone" is heavy, however, the alternative is to write nothing at all

The biggest improvement is the use of a new binary format for storing FRANZBLOCKs.

These are (or rather can) be smaller, reducing (though not by much) the overall size of the archive file.

The side effect is the possibility of "breaking" something.
To maintain some degree of safety, I kept all the old switches and added new ones that end in b (as binary)

So the new blake3 storage format is called -blake3b, while the "historical" one (up to version 59) is called -blake3 (as usual)

Warning: if you do not specify any switch the new default binary format -xxhash64b will be used. If you want to use an old format you MUST specify it explicitly

-frugal

There is one additional significant modification, which can lead to program crashes if misused.
It is the -frugal switch, which reduces memory consumption in storing internal structures (significantly)
This makes sense for storing archives with large amounts of files (10 or 100 MILLION) where the memory occupied can become very large, even exceeding the physical memory of the computer (yes, some people use zpaqfranz to store tens of millions of files)

There are no particular problems in using it IF you do not mix different types (in size of FRANZOblocks)

Translation
Suppose you store within an archive files always with the same hash (the default is xxhash64b).
It doesn't matter which one it is, small (e.g., blake3) or large (e.g., whirlpool)
The problem arises when you create an archive with a small hash (blake3 for example) then add data
with a larger hash (ex whirlpool) and then you want to add data with a smaller one (suppose sha3)
This "mix" of formats will crash zpaqfranz if you use the optional -frugal switch.
So if you always use the same hash you have no problem, you can use -frugal (should you have problems with giant numbers of files)
Or don't use it and live happily
Short version: if you use -frugal DO NOT mix different types of hashes.
If you don't have tens of millions of files to add, -frugal is not needed.

Backward compatibility

Barring bugs the new format can be listed, extracted and added by both zpaq and zpaqfranz up to version 59
Archives created with version 60 (and the new binary format) cannot be tested by earlier versions.
Basically everything works, but the t (test) command loses the ability to check CRC32 codes and, in general, all commands cannot read stored hashes (v command and so on).
Therefore if for some reason you want to maintain 100% backward compatibility with version 59 you have to specify the older versions of the switches (e.g. -xxhash64 or -blake3 or maybe -sha3). Those without the final binary "b".

There is a new -date switch that shows the date the files were created (stored in the new format)

The new format, in addition to being smaller when compressed, also stores the date the files were created. Always (on Windows, by default) and optionally for *nix systems (with the -date switch).
This difference is given by the slower processing of this information (modest on Windows, heavy on *nix)
Also - as is well known - there is no "true" method to determine the creation date on non-Windows systems (the so-called birth date) so zpaqfranz uses a heuristic for the various operating systems, with no guarantee of perfect operation (not my fault)

The new format also stores the number of files added, modified, and deleted for each version

Command l list

The l command has been heavily rewritten, result now slower (!) though more beautiful.
Introduces additional information, such as an estimate of file compression ratio, number of files added (+), modified (#) or deleted (-)
Auto-resizes column size width to maximize space for file names
Uses colors by default (disabled during redirection to files either with system variable NO_COLOR or switch -nocolor to disable)
Changes way of showing up with switches -attr, -checksum (e.g., -crc32), -date, -terse)
A lot of operations are performed that slow down, maybe in the future I will put an uglier but faster version.
More informations here

New list and ads: no way

ADS management has not yet been aligned, so, in case you want to force the recalculation, remember that you can force it to

Backup command with -index

I had a request to make the indexes created by the backup command "mobile" (with the -index switch somewhere). That is, to detach the index files from the archives containing the .zpaq data. The purpose is to make it compatible with Worm systems, writing the data inside a "protected" folder and the indexes in a "normal" one
This, however, makes the backup more fragile, as there is nothing to prevent pairing the WRONG indexes with the .zpaq data
It is up to you to be aware of this and operate accordingly. zpaqfranz cannot do miracles
More informations here

t command with parameters and replace/find/to

A user requested the possibility of using the -test switch, with substitution of strings operated by, for example, -find/-replace, during a test command with parameter (!)
It is quite a complex and specific topic, I leave a link with detailed explanations
More informations here

There is a new compilation switch, -DNAS, which is used to make a mixture of reducing

memory usage and maintaining functionality (in short, it is a relaxed ANCIENT)
It serves, typically, to create executables compatible with the popular Synology and QNAP NAS

autotest

The self-test -all -to something command has been extended considerably.
The generated dotest file operates many more tests, in more areas, some of them deliberately to expected failure,
in short to get a picture I hope fairly reliable

I do not exclude that under certain circumstances it may give false positives, that is, detect errors that are not actually there.
To date it is tested on Windows, Debian, FreeBSD, and QNAP-arm, I have not carried out tests on "weird" things like Macintosh, Solaris, and so on.

The completion time is longer (depends on the speed of the system, of course) even a few tens of minutes or hours on cheap NASes and the space needed is about 15GB (maybe it is too big for small VPS, I will see maybe later)

If you have come this far, and you are very confused, patience

If you have problems open an issue on github or send me a direct email
Remember: the continuous improvement (kaizen) process of zpaqfranz depends on YOU
The more reports and suggestions, the better the program will become