Hacker wrote:but perhaps the config could be stored / edited using the descript.ion of the archive?
Sure, using individual external files might be a solution, though I never was a friend of that concept.
I'm not exactly sure what I would supposed to do with existing descript.ion file entries - append my data somehow? It could break the format.
reg2s wrote:dir1: zpaq l foo.zpaq -until 1
dir2: zpaq l foo.zpaq -until 2
dirN: zpaq l foo.zpaq -until N
Unfortunately this is exactly what I can't do
in the plug-in, as I can't have multiple zpaq "sessions" under the same archive name/listing.
It was already hard to link all temporary data needed for the wcx interface into one session, but this is just not possible with my current plug-in mechanism, as it would brake most things I've already implemented to filter files, dirs and ADS, plus it would use an extreme amount of memory for large archives and make the internal sorting mechanisms quite slow.
reg2s wrote:If acrhive contains hundreds of files it is impractical to select them one by one in branch view. Also if directory tree was packed, not individual files, it is very hard to reconstruct it, as during unpacking files are put in appropriate "archive version names" subdirectories.
I understand what you mean, but that's why I thought of a mapping of some form. Showing a combination of all possible archive "states" is just not practical for large archives IMO, but somehow selecting a specific version to which you want to list might be possible.
I can think of two solutions for now to apply the "-until" option:
I could check whether you try to unpack a complete "archive version" name dir, i.e. you want to copy dir "00000008" or similar out of the archive.
When this is the case, I would internally apply the "-until" option.
But this is flawed due to wcx restrictions, as TC/wcx needs a valid file listing prior to extraction, and so I can't just extract paths/files that TC didn't request in the first place, as TC e.g. creates all dirs by itself prior to extracting and so you'd possibly end up with empty dirs in the target, not actually belonging there.
I need to test whether this is practically possible without breaking too much.
Just creating "dummy" entries in the archive listing and let the user request a specific listing, like
Code: Select all
(of course you would still be able to swap the "0000000N" dirs with the "Show archive version names as detailed timestamp" names)
Now every time you try to extract the "extractme" file, I can make checks for which version you extracted the dummy file and internally apply the "-until" option.
I wouldn't extract the file for real of course, as it would be empty anyway.
Now the trick is that TC re-reads the archive after extraction, so you would immediately have a new archive listing after that, with the "-until" option applied.
The only difficulty is to keep the until number mapped to the archive path in the plug-ins memory pool, in case you close and reopen the archive some time later.
Of course I will have to test this approach for additional practical problems.
What do you think?