Closed Sarpar12 closed 2 years ago
Nothing.
But I do
You find "a feature" (aka: a bug) in 54.11 (not present in 54.10 and earlier).
Please try the attached 54.12a, this should fix the issue
Long version: when extracting with a single "-to" 54.11 check if the output folder is writeable (with enough space), before starting to output something (unless a -space switch is present)
You can see using a fake (inexistent) volume (ex -to m:\)
But there is a bug, from 7.15: a WARNING and not an ERROR is the result
But, if you enter a FILE as a -to, 54.11 make a FOLDER with the same name of the file. 54.12 should take care of this behavior Please let me know if it is OK, I'll release a new build
Thank you very much
On 54.10
C:\zpaqfranz>release\54_10\zpaqfranz x "D:\zpaq.zpaq" "d:/restore/zpaqfranz.exe" -to "m:\"
zpaqfranz v54.10-experimental (HW BLAKE3), SFX64 v52.15, compiled Dec 20 2021
D:/zpaq.zpaq:
1 versions, 2 files, 16 fragments, 1.039.208 bytes (1014.85 KB)
Extracting 1.844.736 bytes (1.76 MB) in 1 files -threads 32
m:: error path not found
MAYBE OUT OF FREE SPACE OR INVALID PATH?
Failed (extracted/total fragments, file):
0/16 m:
Extracted 1 files (1 errors) using 2.165.054 bytes x 32 threads
0.046 seconds (00:00:00) (with warnings)
On zpaq 7.15
C:\zpaqfranz>715\zpaq64 x "D:\zpaq.zpaq" "d:/restore/zpaqfranz.exe" -to "m:\"
zpaq v7.15 journaling archiver, compiled Aug 17 2016
D:/zpaq.zpaq: 1 versions, 2 files, 16 fragments, 1.039208 MB
Extracting 1.844736 MB in 1 files -threads 32
[1..16] -> 1844808
> m:"
m:": path not found
Failed (extracted/total fragments, file):
0/16 m:"
Extracted 0 of 1 files OK (1 errors) using 2.165 MB x 32 threads
0.031 seconds (with warnings)
On 54.11
C:\zpaqfranz>release\54_11\zpaqfranz x "D:\zpaq.zpaq" "d:/restore/zpaqfranz.exe" -to "m:\"
zpaqfranz v54.11-experimental (HW BLAKE3), SFX64 v52.15, compiled Dec 28 2021
Cannot write on <<-to m:>>
Aborting. Use -space to bypass and enforcing.
0.016 seconds (00:00:00) (with errors)
C:\zpaqfranz>zpaqfranz x prova.zpaq -to z:\pippo
zpaqfranz v54.12a-experimental (HW BLAKE3), SFX64 v52.15, compiled Jan 30 2022
prova.zpaq:
1 versions, 1 files, 130.527 fragments, 9.089.688.967 bytes (8.46 GB)
Extracting 9.085.742.813 bytes (8.46 GB) in 1 files -threads 32
Free space on <<-to z:/pippo>>
is 326.815.744
needed 9.085.742.813
Aborting extraction. Use -space to bypass and enforcing.
23013: zpaqfranz error: Not enough free space
0.047 seconds (00:00:00) (with errors)
C:\zpaqfranz>715\zpaq64 x prova.zpaq -to z:\pippo -summary 1
zpaq v7.15 journaling archiver, compiled Aug 17 2016
prova.zpaq: 1 versions, 1 files, 130527 fragments, 9089.688967 MB
Extracting 9085.742813 MB in 1 files -threads 32
3.078 seconds (all OK)
Ok so I tried running the same command(.\zpaqfranz.exe x D:\ZPAQ.zpaq D:/Restore/zpaqfranz.exe -to "D:\SW" -until 2
) in the version you linked in your comment. It returns
zpaqfranz v54.12a-experimental (HW BLAKE3), SFX64 v52.15, compiled Jan 30 2022
D:/ZPAQ.zpaq -until 2:
2 versions, 15.396 files, 147.586 fragments, 7.943.033.988 bytes (7.40 GB)
Non-latin (UTF-8) 4
00000001 ?existing files skipped (-force overwrites).
Extracting 0 bytes (0.00 B) in 0 files -threads 8
I will attach the output of zpaqfranz.exe l D:\ZPAQ.zpaq
here. The file mentioned in this issue is at the end of the output.
This time not my fault :)
You are mixing a FILE extraction with a -to dir
If you want to extract a SINGLE file you must -to... to a single file
something like
c:\zpaqfranz\zpaqfranz x "D:\ZPAQ.zpaq" "d:/Restore/zpaqfranz.exe" -to "d:\extracted\mygoodfile.exe"
Or you can extract everything to a folder
c:\zpaqfranz\zpaqfranz x D:\ZPAQ.zpaq -to d:\outputfolder
If you want to extract a single file to a folder, in fact, you cannot (I am working on this)
zpaqfranz x d:\ZPAQ.zpaq -only d:\Restore\zpaqfranz.exe -to d:\thefolder
or
zpaqfranz x d:\ZPAQ.zpaq -only *zpaqfranz.exe -to d:\thefolder
So I will do a "magic":
if you select EXACTLY one file (without wildcards) and -to to a folder (ending with ) a single file will be created
This could be useful?
Yeah that was my bad. You have fixed the issue for me. A final question about the -only
switch. I extract that to an folder assuming there's multiple objects right?
Well... no
You can select one or more files with -only (and exclude with -notfiles)
Those are arrays
This will work (extract all .cpp and all .txt)
zpaqfranz x z:\uno.zpaq -only *.cpp -only *.txt -to z:\extracted
This will not
zpaqfranz x z:\uno.zpaq *.cpp *.txt -to z:\extracted
The 12.c (attached) handle a "magic" situation Extracting SINGLE file (without wildcards) to a SINGLE folder (AKA: ends with \)
zpaqfranz x D:\ZPAQ.zpaq d:\Restore\zpaqfranz.exe -to d:\myfakefolder
will write a "myfakefolder" FILE (with the binary data of zpaqfranz.exe)
This
zpaqfranz x D:\ZPAQ.zpaq d:\Restore\zpaqfranz.exe -to d:\myrealfolder\
goes to (note the very last \)
C:\zpaqfranz>c:\zpaqfranz\zpaqfranz x D:\ZPAQ.zpaq d:\Restore\zpaqfranz.exe -to d:\myrealfolder\
zpaqfranz v54.12c-experimental (HW BLAKE3), SFX64 v52.15, compiled Jan 30 2022
31744: MAGIC: selected 1 file extracting to a folder => merge to d:/myrealfolder/zpaqfranz.exe
zpaq 7.15, in this case, will make the destination folder, but without output (#1st run)
C:\zpaqfranz>715\zpaq64 x D:\ZPAQ.zpaq d:\Restore\zpaqfranz.exe -to z:\cujo3\
zpaq v7.15 journaling archiver, compiled Aug 17 2016
D:/ZPAQ.zpaq: 2 versions, 53 files, 260 fragments, 2.117487 MB
Extracting 1.844736 MB in 1 files -threads 32
[1..16] -> 1844808
> z:/cujo3/
z:/cujo3/: path not found
0.031 seconds (all OK)
(note: all OK, not very true)
On the 2nd run nothing more
C:\zpaqfranz>715\zpaq64 x D:\ZPAQ.zpaq d:\Restore\zpaqfranz.exe -to z:\cujo3\
zpaq v7.15 journaling archiver, compiled Aug 17 2016
D:/ZPAQ.zpaq: 2 versions, 53 files, 260 fragments, 2.117487 MB
? z:/cujo3/
1 ?existing files skipped (-force overwrites).
Extracting 0.000000 MB in 0 files -threads 32
0.000 seconds (all OK)
I hope zpaqfranz "new" behavior is better and more consistent with a rather frequent operation (single file extraction)
One last warning: beware of case-sensitiveness, you must be careful
I am reluctant to disable it, even partially, because it is quite common to have mixed archives (created on Windows and Linux)
Better: one single zpaq archive, with Windows and Linux data inside
Thank you! It works fine on my end. Imo you should keep case-sensitiveness since I don't really see a benefit in removing it.
I'm going to close the issue now.
Hi. New to zpaqfranz... and I'm unsure if this is a bug or belongs into this thread (as a question)....
zpaqfranz v55.15q-experimental-JIT-L (HW BLAKE3), SFX64 v55.1, (Sep 19 2022)
I want to extract a specific folder (recursively) from an archive into a new folder:
zpaqfranz.exe a "R:\archive.zpaq" "D:\Users\Highend\Development"
zpaqfranz.exe x "R:\archive.zpaq" "D:/Users/Highend/Development/AutoIt/" -to "R:\_extracted_\"
Regardless if "R:\_extracted_\"
exists or not, zpaqfranz puts everything it extracts into the root of "R:"
and prefixes everything with "_extracted_"
(files as well as folders)?
R:\_extracted_Chrome Updater
R:\_extracted_Chrome_Portable
R:\_extracted_ShowHelpFile
...
R:\_extracted_ShowHelpFile.au3
etc.
Am I doing something wrong here?
You should do
zpaqfranz.exe x "R:\archive.zpaq" "D:/Users/Highend/Development/AutoIt" -to "R:\_extracted_\"
(no / after AutoIt)
This is the very infamous last \ on Windows command line
else if (opt=="-to")
{ // read tofiles. Possible collision with -tthread
while (++i<argc && argv[i][0]!='-')
{
// fix to (on windows) -to "z:\pippo pluto" going to a mess
string mytemp=mytrim(argv[i]);
myreplaceall(mytemp,"\"","");
tofiles.push_back(mytemp);
}
if (tofiles.size()==0)
tofiles.push_back("");
--i;
}
Short version: yes, \ does matter Maybe I will make a kludge for this case
Thanks for signaling
Mid-sized version
Original zpaq 7.15 will fail in this case, here just an example
(look @ double quotes)
C:\zpaqfranz>715\zpaq64 x "z:\archive.zpaq" "p:\users\highend\development\autoit\" -to "z:\test715\"
zpaq v7.15 journaling archiver, compiled Aug 17 2016
z:/archive.zpaq: 1 versions, 7 files, 43 fragments, 0.870572 MB
Extracting 0.000000 MB in 0 files -threads 32
0.015 seconds (all OK)
C:\zpaqfranz>715\zpaq64 x "z:\archive.zpaq" p:\users\highend\development\autoit\ -to "z:\test715\"
zpaq v7.15 journaling archiver, compiled Aug 17 2016
z:/archive.zpaq: 1 versions, 7 files, 43 fragments, 0.870572 MB
Extracting 3.854991 MB in 2 files -threads 32
[1..40] -> 2452972
> z:/test715" nonva.cpp
z:/test715" nonva.cpp: invalid name
> z:/test715" nonva1.cpp
z:/test715" nonva1.cpp: invalid name
Failed (extracted/total fragments, file):
0/36 z:/test715" nonva.cpp
0/36 z:/test715" nonva1.cpp
Extracted 1 of 3 files OK (2 errors) using 4.262 MB x 32 threads
0.016 seconds (with warnings)
But works fine without "
C:\zpaqfranz>715\zpaq64 x "z:\archive.zpaq" p:\users\highend\development\autoit\ -to z:\test715\
zpaq v7.15 journaling archiver, compiled Aug 17 2016
z:/archive.zpaq: 1 versions, 7 files, 43 fragments, 0.870572 MB
Extracting 3.854991 MB in 2 files -threads 32
[1..40] -> 2452972
> z:/test715/nonva.cpp
50.01% 0:00:00 > z:/test715/nonva1.cpp
0.016 seconds (all OK)
C:\zpaqfranz>715\zpaq64 x "z:\archive.zpaq" p:\users\highend\development\autoit -to z:\test715_2
zpaq v7.15 journaling archiver, compiled Aug 17 2016
z:/archive.zpaq: 1 versions, 7 files, 43 fragments, 0.870572 MB
Extracting 3.854991 MB in 2 files -threads 32
[1..40] -> 2452972
> z:/test715_2/nonva.cpp
50.01% 0:00:00 > z:/test715_2/nonva1.cpp
0.031 seconds (all OK)
If you are curious I can make the "spiegone" (aka: long explanation), I choose to prefer the " to maintain spaces (aka: "pippo pluto")
Thanks for the clarification and the explanation! You don't need to do a long version :)
It works fine here as well if I leave out the final slash for the pattern / path
So you'll get... the "intermediate"... version :)
A not very well known feature of Windows is the "escaping"
backslash" means... "
This brings to a mess (note prova)
C:\zpaqfranz>zpaqfranz.exe x "z:\archive.zpaq" pippo -to "z:\prova\" -verbose
ZZZZZZZZZZZ |zpaqfranz.exe x "z:/archive.zpaq" pippo -to "z:/prova/" -verbose|
zpaqfranz v55.16f-experimental-JIT-L archiver, SFX64 v55.1, (02 Oct 2022)
mycommandline |zpaqfranz.exe x "z:/archive.zpaq" pippo -to "z:/prova/" -verbose|
i_command |-to|
i_parameter |z:/prova" -verbose|
The right way is a double backslash (look carefully at prova)
C:\zpaqfranz>zpaqfranz.exe x "z:\archive.zpaq" pippo -to "z:\prova\\" -verbose
ZZZZZZZZZZZ |zpaqfranz.exe x "z:/archive.zpaq" pippo -to "z:/prova//" -verbose|
zpaqfranz v55.16f-experimental-JIT-L archiver, SFX64 v55.1, (02 Oct 2022)
mycommandline |zpaqfranz.exe x "z:/archive.zpaq" pippo -to "z:/prova//" -verbose|
i_command |-to|
i_parameter |z:/prova/|
But almost none, even myself, remember this rule (the double backslash)
So it is usually easier... no backslashes at all
If you have any suggestion for zpaqfranz please tell my
I'm using Windows since Win 95 but I've never stumbled upon that one^^
Oh, I have a suggestion for zpaqfranz but I don't think you'll implement that :)
It doesn't store all metadata (like ACLs) and that's fine for me but there is one thing that I really don't like... It isn't able to set the created date for files / folders that it extracts from an archive (because it didn't store it in the first place?)...
This may be a rather normal thing on linux derivates (not storing created dates) but it isn't on Windows.
E.g. imagine you have a file "Letters to girlfriend.docx". It may have been modified 8 days ago but it was created 20 years ago. If a file that written out with the current date (for created) you wouldn't even know when you started that document (when you restore it), only when you last modified it. Created date matters (at least on Windows)^^
Any chance that you include that date when adding to an archive and set a file / folders date to that one when extracting from it? At least via an option like -cdate
?
A really hard request, indeed :-) Not easy because it requires quite an extensive modification in order to maintain backwards compatibility
On Windows there are 3 different dates: lpCreationTime, lpLastAccessTime, lpLastWriteTime
Only the last is stored as now
Anyway I can do (even if it will be a mess) Any other suggestions?
PS working as now (aka: choosing the hash function) is too hard for the new function (aka: require a LOT of work)
I will make a fixed-type hasher.
If you use -cdate (on Windows) the creation/last access dates will be stored, with CRC-32 and xxh3. You cannot choose other hash (ex. SHA-2, SHA-3 etc)
Is it enough?
Mh. Afaik you can only extract either all versions or only a single one. If that's true I'd really like to see the -until
feature expanded. E.g. with ranges.
Just a few suggestions:
-until 2:4 -> Extract all versions from 2 to 4
-until 2: -> Extract all versions from 2 to <all that exist>
-until :3 -> Extract all versions from 1 to 3 (equal to: 1:3)
I would use the second example extensively, e.g. just extract the last 5 versions, see which one I need from them...
When I start using zpaqfranz for real backups (with a version that supports lpCreationTime) I'll probably stumble about more things that may be convenient...
Regarding your last question about if that would be enough: I'm fine with CRC-32 and xxh3 only, both are very fast hashing routines (benchmarked them on my system when I first started zpaqfranz) ...
Mh. Afaik you can only extract either all versions or only a single one. If that's true I'd really like to see the
-until
feature expanded. E.g. with ranges.
You can use my old GUI (pakka) :-)
Anyway, it is doable (slow, but doable)
No, I wouldn't want to use a GUI for it; in the end I'll script everything anyway :)
In the attached pre-build (non finished! extract only added files) you will find 55_16g.zip the new range switch
zpaqfranz x versioni.zpaq -to z:\destination -all -range 2-4
zpaqfranz x versioni.zpaq -to z:\destination -all -range 2-
zpaqfranz x versioni.zpaq -to z:\destination -all -range -3
zpaqfranz x versioni.zpaq -to z:\destination -all -range 2
Is it OK for you?
Works perfectly fine, great addition, thanks!
Beware, this will extract the "embedded" files into the versions. DO NOT extract everything.
If version 1 si 10GB, and version 2 10K, version 3 20K, version 4 5K, and you extract version 2-3, you will get 30K
A really full extract will need to make 10GB (version 1) 10GB+10K (version 2) 10GB+10K+20K (version 3) (...)
I thought it was to archive the sources and quickly extract the differences.
For example, if you want to get what is changed in the compagnie.pas file, from 100 to 1000 version, this will work
zpaqfranz x copia_zarc.zpaq -only *compagnie.pas -to z:\tuttecompagnie -all -range 100-1000
Ok, noted
55_16h.zip
The pre-release build have a new switch: -windate
(as now do not update creation date, only store-show)
Use XXHASH64 (instead of xxh3) as zpaqfranz by default
zpaqfranz a z:\test *.txt -windate
zpaqfranz l z:\test.zpaq -windate
zpaqfranz v55.16h-experimental-JIT-L (HW BLAKE3), SFX64 v55.1, (03 Oct 2022)
franz:winhash64 (-windate)
z:/test.zpaq:
1 versions, 11 files, 11 fragments, 3 blocks, 20.593 bytes (20.11 KB)
- 2022-10-03 18:39:37 (C) 2022-08-12 18:59:02 0 A 1.txt
- 2022-09-17 16:56:17 (C) 2022-09-15 16:06:52 570 A 2.txt
- 2022-09-18 15:12:54 (C) 2022-08-25 16:49:36 874 A 3.txt
- 2022-09-18 15:12:54 (C) 2022-08-25 16:50:23 426 A 4.txt
- 2022-09-08 15:54:43 (C) 2022-08-12 16:24:16 13.050 A cpuz.txt
- 2022-09-08 15:54:43 (C) 2022-08-12 19:56:11 153 A lavoretti.txt
- 2022-09-18 19:25:43 (C) 2022-09-18 19:25:41 190 A news.txt
- 2022-09-08 15:54:43 (C) 2022-09-07 10:12:57 21.966 A nz.txt
- 2022-09-08 15:54:43 (C) 2022-09-07 10:36:54 1.398 A nz2.txt
- 2022-09-08 15:54:43 (C) 2022-08-26 13:52:12 14.338 A provapc.txt
- 2022-09-08 15:54:43 (C) 2022-08-14 16:45:52 434 A thelog.txt
53.399 (52.15 KB) of 53.399 (52.15 KB) in 11 files shown
20.593 compressed
0.032 seconds (00:00:00) (all OK)
Do you like?
Looks great!
I'll finish tomorrow
Nothing else?
Let me work with it for a while when it's released. I'll get back to you if I find things to improve :)
Released 55.16 now
A lot of changes :) Nice to see that there is still a lot of room for improvement!
I've used -windate (for adding and extracting) now and I've noticed a small glitch on extracting...
It seems you're setting the modified time of extracted folders (it doesn't happen with files) with the value of the created time as well. Can you check that please?
It is a feature :) You do not like?
No, it's a bug :)
The modified time for folders should be set (if they were stored with -windate previously) to their former modified time, not the stored creation time
For folders a lot of work is needed, with some space wasted. I am not 100% convinced
I know (that this isn't an easy task to do it right) but please invest that time. If you need to restore a folder structure you'll want to get it in the original state, not in some "ok, modified times are fu****" up state :) Thanks!
So im trying to use
.\zpaqfranz.exe x D:\ZPAQ.zpaq D:/Restore/zpaqfranz.exe -to "D:\SW" -until 2
in powershell, since my archive is D:\ZPAQ.zpaq. In that archive is the fileD:/Restore/zpaqfranz.exe
and I want to extract it to D:\SW. However the output I get iszpaqfranz v54.11-experimental (HW BLAKE3), SFX64 v52.15, compiled Dec 28 2021
D:/ZPAQ.zpaq -until 2:
2 versions, 15.396 files, 147.586 fragments, 7.943.033.988 bytes (7.40 GB)
Non-latin (UTF-8) 4
000001 ?existing files skipped (-force overwrites).
`Extracting 0 bytes (0.00 B) in 0 files -threads 8``
What am I doing wrong?