Inconsistent longpath switch' behaviour

[Werve]

First of all, is it possible to store individual files with the -longpath parameter?

From a quick test it does not seem possible.

If I try to archive without longpath the expected behavior occurs and only the described file is processed.

zpaq.exe -method 1 -windate a "C:\Program Files\PeaZip\res\bin\zpaq\test.zpaq" "C:\Program Files\PeaZip\res\bin\zpaq\zpaq.bat"
zpaqfranz v58.11z-JIT-GUI-L,HW BLAKE3,SHA1/2,SFX64 v55.1,(2023-11-10)
franz:-method                                   1
franz:-windate
Creating C:/Program Files/PeaZip/res/bin/zpaq/test.zpaq at offset 0 + 0
Add 2024-01-12 19:57:39         1                155 (  155.00 B) 8T (0 dirs)
1 +added, 0 -removed.

0 + (155 -> 155 -> 1.305) = 1.305 @ 828.00 B/s

0.187 seconds (000:00:00) (all OK)

But if instead I add longpath it seems to work only on the entire directory, adding all the files in the parent directory into the archive.

zpaq.exe -method 1 -windate -longpath a "C:\Program Files\PeaZip\res\bin\zpaq\test.zpaq" "C:\Program Files\PeaZip\res\bin\zpaq\zpaq.bat"
zpaqfranz v58.11z-JIT-GUI-L,HW BLAKE3,SHA1/2,SFX64 v55.1,(2023-11-10)
franz:-method                                   1
franz:-windate -longpath
38992: INFO: getting Windows' long filenames
Creating C:/Program Files/PeaZip/res/bin/zpaq/test.zpaq at offset 0 + 0
Add 2024-01-12 19:56:47         5          7.651.483 (   7.30 MB) 8T (0 dirs)
38385: WARN expected                   0 getted           3.262.976 for C:/Program Files/PeaZip/res/bin/zpaq/zpaq.exe
5 +added, 0 -removed.

0 + (7.651.483 -> 4.388.507 -> 2.258.682) = 2.258.682 @ 9.53 MB/s

38271: HOUSTON expected 7.651.483, done 10.914.459, diff 3.262.976
38271: Corrupted source files? Lost connection? Cannot access? Media full?
38271: =>The updated .zpaq archive is almost certainly incompleted

0.781 seconds (000:00:00) (with errors)

Complimenti per il programma!

I am recently trying to use it with the PeaZip GUI hoping to find one for the zpaq format that will allow extraction of individual files, folders, and a tree preview of archived folders as one might normally encounter with other formats. Unfortunately, so far I have not found any GUI that allows this.
Usually they all extract the entire archive by recreating a complete path instead of, for example, just the selected folders (as can also be done with WinRAR and the tree view)

[fcorbelli]

You can try PAKKA (as an extractor)
For longpath I'll check tomorrow

[Werve]

Yes, I tried PAKKA and it's the only GUI I found that handles multiple versions, but unfortunately it doesn't have a tree view (like Windows or winRAR) to allow a simple extraction, for example, of specific folders.
It also lacks the ability to add additional flags such as -windate and the ability to select via text path, the files or folders to be added to an archive

[fcorbelli]

Well, you can extract specific folders with PAKKA

For additional flags you just ask and I'll do 😄

[fcorbelli]

58_13n.zip
You can try this VERY EXPERIMENTAL build, with (partial) support with -longpath for files
-longpath is... for path, not for files
I do not think this can run on XP
Just a quick-and-dirty try

[Werve]

58_13n.zip You can try this VERY EXPERIMENTAL build, with (partial) support with -longpath for files -longpath is... for path, not for files I do not think this can run on XP Just a quick-and-dirty try

I tried it and now it works correctly for files both with actually a long path (>255) and in a normal one.
But it no longer seems to work for folders, using -method 1 -windate -longpath a "D:\Download\Nuova cartella\Nuova cartella.zpaq" "D:\Download\Nuova cartella\Nuova cartella\*" "D:\Download\Nuova cartella\Nuova cartella (2)\*"

zpaqfranz v58.13n-JIT-GUI-L,HW BLAKE3,SHA1/2,SFX64 v55.1,(2024-01-08)
franz:-method                                   1
franz:-windate -longpath
INFO: getting Windows' long filenames
sorry, cannot get -longpath for this file <<D:/Download/Nuova cartella/Nuova cartella/*>>
-longpath is... for PATH, not FILE
0.031 seconds (000:00:00) (with warnings)

Previously this command worked.

Well, you can extract specific folders with PAKKA

For additional flags you just ask and I'll do 😄

Yes, I saw but I can't, for example, use ctrl key to select multiple folders to extract them together, or visually notice the top folders immediately.

[fcorbelli]

(1) "", or "?", or ".*" cannot work
There is no "serious" function in the Windows API to do something as trivial as locating the real name of a file. The "best" function, which works in almost every case, involves using COM, and I don't want to do that (too slow and too high a risk of leakage when used for thousands and thousands of calls, Scripting.FileSystemObject with GetAbsolutePathName)
Now I take from KERNEL32.DLL

getFinalPathNameByHandleW=(GetFinalPathNameByHandleW_t)GetProcAddress(h, "GetFinalPathNameByHandleW");

But I need a Windows XP VM to test on older Windows
If there were, incidentally, there would be no need to do the "multiple screwing somersaults"
So, to recap, -longpath is designed for long PATHS, i.e., folders. Certainly not for individual files.

Short version: not a priority, I am working on a very complex evolution that is absorbing me (multipart archives of fixed size with encryption)

Regarding PAKKA it is easy to evolve it, I am the God of Delphi 😄

[ruptotus]

For extract sometimes I use Bandizip:

But it "officially" supports original zpaq not zpaqfranz specifically but I did not have any problems (but cautions is advised). It also works with password protected archives.

[fcorbelli]

I worked very hard to maintain backward compatibility. Any program that "understands" zpaq is automatically compatible with zpaqfranz. However, as far as I know, there is no extractor that supports longpaths, other than PAKKA. In the future version (of PAKKA) I will implement listing mode with ADS, which basically guarantees listing files in no more than 1 second, whatever the size of the archive (on Windows). The other extractors also do not support "time machine" viewing, i.e., different versions of the same file. In the case of PAKKA it originated 10 years ago to archive mysql backups, as a Delphi form of a more extensive program of mine (an ERP). This, incidentally, is "why" it is essentially in Italian.
From 2014 to 2024 I have had one, two and now three reports of using PAKKA (!), I have not evolved it at all.
I am in the process of reaching the "optimal" level of zpaqfranz, that is, the one where it does everything I set out it would do (it lacks encrypted multipart at set size)
Then, perhaps, I will work more on PAKKA.

[aleksandrmelnikov]

I've found that using a zip file with 0 compression, then using zpaq to
Deduplicate and store.. has been working fantastic.