Bug: -verify -paranoid -test does not work with zpaqfranz a store.zpaq 'long_path_windows_dir' -longpath

[aleksandrmelnikov]

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

[aleksandrmelnikov]

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.

[fcorbelli]

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

[aleksandrmelnikov]

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.

[fcorbelli]

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