Ran a command, program suddenly stop (crash I think, its leave 0 byte zpaq file) without any notice

[Namke]

Just happen like title, there are no dump or whatsoever, happen in Windows version of one machine, Ubuntu version on other machine ran for awhile then crash. All other machine ran fine. Version were 60a latest. Full command + log in the screenshot.

[fcorbelli]

-hw is not needed -checksum and -blake3 are incompatible -paranoid is redundant -blake3 is the old format - blake3b is the newer (60+)

It seems like you are trying to update an existing archive, perhaps made with a different format. I don't recommend that. In version 60.3 I put an enhanced dump that tells you the file format.

[Namke]

I tried again on blank slate with -longpath -m3 -verbose -chunk 4g -blake3b -paranoid -filelist, seem its working fine (compressing now). Quick questions:

• Do the new blake3d could be added to existing archive?
• Reason program exist without notice seem confusing, is there are any method to verify the reason?

[fcorbelli]

Do the new blake3d could be added to existing archive?

It depends on what kind (what hash) of archive is

Reason program exist without notice seem confusing, is there are any method to verify the reason? You can try the dump command (does not work on very complex archives)

[fcorbelli]

Slightly longer explanation There is no archive format in zpaq files (it would be nice if there was, but there isn't) So zpaqfranz cannot determine ex ante what type of archive you are processing It only knows ex post (i.e., after processing it) This causes that mixing different versions can general problems (indeed, in general it does) In the changelog I put some examples

[Namke]

Let say all previous compression were made with -blake3, is that ok to update with -blake3b?

Maybe I get an idea wrong, but I'm under impression that zpaqfranz is backward compatible, so let say initial compression is with -checksum, second with -blake3, and then now goes with -blake3d; its suppose to be safe, no?

[fcorbelli]

In theory, yes, and the new version of the self-test command purposely mixes the format of the files In fact, I haven't tried it at all with -checksum I am still doing my tests, so far I have not encountered any problems. However, like all innovations, you need production testing (which I am doing)

Short version: if the procedure of a (add) ends, you can be reasonably sure that you can extract the data anyway. No one forbids you from using the t command to make sure. I am now doing Macintosh fixes (which has a terminal with a white background instead of black). In 10 or 15 days I will upgrade a large ESXi server and there I will do all the testing in the world for version 60

PS it is "b" as "binary" or "bis" 😄

[fcorbelli]

BTW thank you for detecting one "bug" You CANNOT select more than one hash (ex no -blake3 -whirlpool) but YOU can use -checksum I'll fix in next release

[Namke]

I'm ran t on my whole archive (again) to verify now, just to be sure. Anw, perhaps you should create an Discord, its better to discuss in advance before spawn an ticket on Github I think.

[fcorbelli]

No big deal, they are free :)