Bug: -verify -paranoid -test does not work with zpaqfranz a store.zpaq 'long_path_windows_dir' -longpath
aleksandrmelnikov opened this issue · comments
Hello!
I absolutely love this tool and seeing how you improve it.
Thank you.
I find it a joy to deal with windows longpaths, and I am sure you do too ;).
Here's the issue I've run into.
First, zpaq version.
zpaqfranz v58.7k-JIT-GUI-L,HW BLAKE3,SHA1/2,SFX64 v55.1,(2023-07-24)
Usage: zpaqfranz command archive.zpaq files|directories -switches
double quote for multipart archive name => "test_???.zpaq"
Here's the command I ran.
PS D:\zpaq> .\zpaqfranz.exe a .\email_in_container_2.zpaq 'I:\desktop-ekf8q7u_2021_04_03_1-18-5-28-17\E\Easeus 06 13_18\3TBGreen001(I)\Lost Files\Existing Partition\EmailArchiverPro' -longpath -paranoid -test -sha3 -verify -summary
It added the files fine (yay!), but the verification code doesn't seem to be able to read long paths?
3TBGreen001(I)/Lost Files/Existing Partition/EmailArchiverPro/sturakov@fastmail.fm/INBOX.Upload Area.Fastmail Download/2017/09/2017-09-08 22.42.18Z City of Dallas seeks input on proposed park renovations.pdf>>
48699: error kind 3 ERROR_PATH_NOT_FOUND opening <<I:/desktop-ekf8q7u_2021_04_03_1-18-5-28-17/E/Easeus 06 13_18/3TBGreen001(I)/Lost Files/Existing Partition/EmailArchiverPro/sturakov@fastmail.fm/INBOX.Upload Area.Fastmail Download/2017/09/2017-09-08 22.47.03Z ALCGENL 133 17 - AY18 ELECTRICIANS MATE ENGINEER PETTY OFFICER (EPO) SCREENING RESULTS.pdf>>
48699: error kind 3 ERROR_PATH_NOT_FOUND opening <<I:/desktop-ekf8q7u_2021_04_03_1-18-5-28-17/E/Easeus 06 13_18/3TBGreen001(I)/Lost Files/Existing Partition/EmailArchiverPro/sturakov@fastmail.fm/INBOX.Upload Area.Fastmail Download/2017/09/2017-09-08 22.49.52Z CORRECTION Port of Seattle Connections, Sept. 8, 2017.pdf>>
--------------------------------------------------------------------------------------------------------------------
OK SHA-3 : 00119876 of 00237811 ( 15.26 GB hash check against file on disk)
WARN SHA-3 : 00117935 of 00237811 (file not found, cannot check hash)
I had a similar thing happen with 1on1 command.
48699: error kind 3 ERROR_PATH_NOT_FOUND opening <<I:/desktop-ekf8q7u_2021_04_03_1-18-5-28-17/E/Easeus 06 13_18/3TBGreen001(I)/Lost Files/Existing Partition/EmailArchiverPro/sturakov@fastmail.fm/INBOX.Upload Area.Fastmail Download/2017/09/2017-09-08 22.49.52Z CORRECTION Port of Seattle Connections, Sept. 8, 2017.pdf>>
63992: Same hash 992.000.149 (same name too) 000.149
63995: To be deleted 196.885 (same name, same hash)
63996: DRY RUN because no -kill switch entered
I used the 1on1 because I extracted that container, and I wanted to see if there were any files that didn't get added correctly.
I'm currently trying the 1on1 command without the -longpath switch. I'll post results when it completes.
At 99% yes, it is a bug in the -longpath
Where? I really do not know
Please report the output of the attached pre-release
58_8c.zip
Mixed results here.
It looks like it worked for the a command.
PS D:\zpaq> .\zpaqfranz_58_8c.exe a .\email_in_container_testing.zpaq 'F:\Recovered\Local Disk(G)\Deleted Files\EmailProcessing\[EAP''D - 12-2020] GmailEmls\GmailEmls\DownloadArchiveDelete-Dec282019\__MACOSX\Messages\' -longpath -sha3 -summary -test -paranoid -verify
zpaqfranz v58.8c-JIT-GUI-L,HW BLAKE3,SHA1/2,SFX64 v55.1,(2023-07-30)
franz:-summary 1
franz:-sha3 -hw -longpath -paranoid -test -verify
38992: INFO: getting Windows' long filenames
59838: Trimmed last / F:/Recovered/Local Disk(G)/Deleted Files/EmailProcessing/[EAP'D - 12-2020] GmailEmls/GmailEmls/DownloadArchiveDelete-Dec282019/__MACOSX/Messages
Creating ./email_in_container_testing.zpaq at offset 0 + 0
Add 2023-08-05 21:49:48 253.135 0 ( 0.00 B) 16T (0 dirs)
253.135 +added, 0 -removed.
0 + (0 -> 0 -> 5.297.089) = 5.297.089 @ 0.00 B/s
====================================================================================================================
Compare archive content of:./email_in_container_testing.zpaq:
1 versions, 253.135 files, 5.297.089 bytes (5.05 MB)
Scanned 1 00:23:27 0 file/s ( 0)
253.135 in <<//?/F:/Recovered/Local Disk(G)/Deleted Files/EmailProcessing/[EAP'D - 12-2020] GmailEmls/GmailEmls/DownloadArchiveDelete-Dec282019/__MACOSX/Messages/>>
Total files found: 253.135
Done 99% 0.00 B of 0.00 B, diff 0 bytes so far
00253135 = same
Total different file size: 0 bytes
====================================================================================================================
./email_in_container_testing.zpaq:
1 versions, 253.135 files, 5.297.089 bytes (5.05 MB)
Verify hashes of one version vs filesystem (1 thread, -ssd for multithread)
1421.172 seconds (000:23:41) (all OK)
But 1on1 reported the same error.
I haven't tested the new release yet.
Thanks, but I really need the full output with -debug, to catch the exact position of the file hashing (for a command)
For 1on1 I need an example too