Machine-parseable output (-terse ?) and failure to restore a file
#120
Comments
|
By the way this is the crazy insane pipeline I am using now to choose the file for restore (I will pass the version and filename to zpaqfranz l backup.zpaq -find "20240516101824054.png" -all -terse |
grep -v ^deleted |
cut -c53- |
awk 'BEGIN { FS="|"; OFS="\t" } { print $1, substr($2,4) }' |
fzf --exact --multi --no-select-1 --header "Ver$'\t'Filename"😐 |
|
And yet even with all that hand-waving, I still can't figure out how extract the file I need... FAIL 1FAIL 2FAIL 3The .zpaq archive seems ok... $ zpaqfranz t backup.zpaq
zpaqfranz v60.5e-NOJIT-L(2024-07-20)
backup.zpaq:
2718 versions, 86.547 files, 1.230.674.231 bytes (1.15 GB)
To be checked 1.352.276.056 in 22.853 files (8 threads)
7.15 stage time 33.19 no error detected (RAM ~128.52 MB), try CRC-32 (if any)
Checking 23.266 blocks with CRC-32 (1.352.276.056 not-0 bytes)
Block 00022K 1.22 GB
CRC-32 time 0.39s
Blocks 1.352.276.056 ( 23.266)
Zeros 0 ( 0) 0.000000 s
Total 1.352.276.056 speed 3.494.253.374/s (3.25 GB/s)
GOOD : 00022853 of 00022853 (stored=decompressed)
VERDICT : OK (CRC-32 stored vs decompressed)
33.572 seconds (00:00:33) (all OK) |
luckman212
changed the title
-terse ?)-terse ?) and failure to restore a file
|
I am a bit confused, there are numerous topics (already answered, but rewriting) 1) Extracting a single file to a SINGLE FILEPlease note: this is A FILE, not A FILE TO A FOLDER You can use more than one way (usually on the "complexity" of the filename) The "standard" way: use the fullname and -to A FILE (not a folder) zpaqfranz x thearchivename THEFULLFILENAME -to THEFULLEXTRACTEDFILENAME -until THEVERSIONYOU WANT Let's suppose you want to extract the file f:/zarc/inctrl/readme.txt of the version 659 |
2) A file TO A FOLDERIn this example in the z:\ugo folder. Please note the -only If the filename is unique you can use *filename to extract to A FOLDER (in this example the z:\allread) |
If you use "something" (-all, -range or whatever) then you will go to "show-everything-in-the-archive" |
|
Ok, this worked: I feel very dumb when trying to figure out zpaqfranz syntax. Thank you for the working command. 🙏 |
|
When running on *nix beware that a -space should be handy extracting to non-existent paths TRANSLATION when you extract something to /my/good/path zpaqfranz will try to figure if /my/good/path does exists, is writeable and there is enough freespace. This is easy for Windows, virtually impossible for *nix. If you wonder why it is relative to the risk of filling a path, that is, running out of free space. This is a very frequent nightmare for people making batch copies. The execution ends, but the written file is incomplete, and therefore unserviceable Short version: if in doubt, put -space |
|
The syntax of zpaqfranz is indeed strange, but it was introduced by its originator (Dr. Mahoney) and I have retained it for backward compatibility, with some mitigation Remember that you can extract a PATH TO A PATH and a FILE TO A FILE, but you cannot extract a FILE TO A PATH Last but not least (!) zpaq use -to, and zpaqfranz added -find and -replace to manipulate paths |
|
This should be OK (assuming only a single file with this name) |
|
On -terse
Suppose you have a $$$$$$$$$$$$$$$$$$.cpp file Version 3 is the very last recoverable version of this file |
|
You want ALL the versions of this file This is padded to 8 |
|
BTW zpaqfranz h x
|
|
The -find is just about |grep on systems where grep does not exists |
|
Thank you for all of this. I didn't mean to accuse you of creating this arcane syntax. I understand it was inherited. Back to what is actually my original question. About Yes I see it is fixed-width, hence I am "parsing" it using simple tools like But, would you consider adding a flag to convert the space-delimited output to tabs instead? It would make the parsing more reliable in my opinion. |
Of course I can |
|
Yes TAB between each column would be ideal. I always prefer TAB because filenames can contain commas. 👍 of course ... |
The very best is | (cannot be in filename) but it is hard to parse |
You sure about that? 😉 
|
|
I do not use Mac 😄 OK, a programmable one... |
|
Best is probably the If you would like a Mac to test with I can ship you my old MacBook Air 2015 (only runs up to macOS 12.x Monterey but otherwise works fine) for free. |
|
Houston we have a problem with \t 😄 PS thank you, but I have a PowerPC Minimac (!!!!!!!) per hard-code tests |
|
60_6e.zip Do you want a string AFTER the file name? |
|
Thank you! Almost, but not quite (spaces should not be there, and delimiter should not be repeated, just 1 per field): should be
No. |
|
mmmhhh... I will finish tomorrow |
|
60_6g looks pretty good! Only thing I see is an extra space before the file mode. Not sure if that's intentional 
One other thing, the Is that intentional? |
|
|
With -terse -all I cut off the version infos. Much easier parsing |
|
60_6g working perfectly! A thing of beauty! |
|
Update: still working well. I would consider this solved @fcorbelli Thank you very much again for the wonderful tool. |
|
Just to chip in - this looks great adding more things to programmatically control and build on top of zpaqfranz :D |
Related to #63 I am trying to adapt my script to extract a specific version of a file in my archive. I'm using macOS 14.5, zpaqfranz v60.5e-NOJIT-L(2024-07-20) from Homebrew on M1 Mac.
For example, I want to restore version 2178 of
IMG-20240516101824054.pngbelow:What is the most efficient command to do this based on the output? I noticed the fields are space-delimited (not tab) which makes it harder to parse (what if file name contains spaces?) I believe
-terseshould useNULbyte orTABas field delimiters.Also, if I don't specify
-allthen I get zero output. Is that correct? (Yes the original file was deleted). Is there any way tofindorlistonly recoverable files? This is why I am trying to parse the output of-allby the way, since I need to filter out anything that saysdeleted/inacessible)The text was updated successfully, but these errors were encountered: