@brian-gregory problem for 7z and PA formats is when multi-threading is enabled, current file progress could cause issues due to it reporting from multiple different threads to the main thread. So
Previously we simply did not have MT support for 7z due to this issue.
@spwolf said in PACL for Linux:
i guess we will have to make linux version when PAF is out…
I thought I’d revive somebody else’s thread
I already heard from Drazen that we’re not quite ready with a Linux PACL yet, but it probably bears repeating that there’s interest in that, still; Now that .pa is ‘in the wild’, so to speak, timetables are narrowing for compatibility with other OS’s.
I have archive that holds password protected, encrypted data which is created using something like this:
C:\Temp\ZipTest>pacomp -a -spassword -fips -e2 archive.zip "C:\Temp\ZipTest" -x"C:\Temp\ZipTest\ReadMe.txt"
Then I add regular file into that archive which is not encrypted and not password protected. “ReamMe.txt” sort of file. Using command below.
C:\Temp\ZipTest>pacomp -a archive.zip "C:\Temp\ZipTest\ReadMe.txt"
Now when I extract this archive using:
paext -spassword -p"C:\ZipTest\Temp" archive.zip
Everything extracts correctly except for ReadMe.txt file. File is present but content is empty.
I get following
error: extracting: ReadMe.txt --> CRC ERROR! [100%]
How can I extract archive without corruption ReadMe.txt file?
If you use regular PA, you can create a backup job (.pbs file) and one of the option is a time (and size) filter. You can set a specific date – or specify files created or changed in the last x number of hours, days, etc. (see the attached image)
'Create the string with parameters for PACOMP
strCompressionString = PACOMP & " -a -P " & Chr(34) & ArchiveName & Chr(34) & " " & Chr(34) & pstrFileName & Chr(34)
WshShell.Run strCompressionString, 0, True
```The command and the parameters sent to PACOMP will be displayed when you run the script.
Look at this line in the script
strCompressionString = PACOMP & " -a -P " & Chr(34) & ArchiveName & Chr(34) & " " & Chr(34) & **pstrFileName** & Chr(34)
What's the value of **pstrFileName** when you run the script? Is it only the filename or is it the filename with the full path?
There’s nothing you can do about it. If you have forgot your password, then the content of the zip file is lost forever. The whole point of using passwords on archive is to prevent access to it if the password is incorrect.
There are several requests I have offered several times. Perhaps there are technical reasons why you cannot do any of these. But let me offer them again. They all concern AC:
I standardly get 2-3 acknowledgments of an AC download. Perhaps some of that is caused because some people have their email forwarded from one server to another . . . so the download notification gets keyed by each server.
could you please note that the time you are using for download time – so that users will know that the time listed is 5-8 hours off that of US users?
could you give users a way (a) to delete all AC filenames, and (b) to show us which files are still active for download? Actually, I would prefer that AC delete file names once their download date has passed.
This would make AC more attractive (unless, for cost reasons, you would prefer not to make it more attractive – which I would regret, but understand).
You’ve been busy Nice!
OK, it looks like you used the text from manual.txt as the basis of the wiki. Initially, I’d like to see a short explanation of each command and it’s capabilities\requirements at the top of the wiki so it’s the first thing you see in the wiki - sort of an expanded whatsnew.txt for each command - with links to the syntax of each command. Is there a reason why PAEXT is first. I’d have thought you compress then uncompress so PACOMP followed by PAEXT maybe?
(These are just my thoughts so anyone else please sound-off).