@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.
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.
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).
Hello, i found a “folder Date” bug in conversion of archives. After conversion looks all OK … but if you unpack the converted archive, date for all folders and sub-folders doesn’t match to date stored in archive.
This bug occurs for all converted archives types (7-zip, cab, rar, tar, Lha, Bh …) except zip. (after unpacking all dates for “zip” are OK)
“Rar” archive: There is a another bug. If you convert archive eg. from zip -> Rar all folder structure is lost. There are only files no folders. Message “Some archives have not been converted”
Note: DATE bug
Similiar bug “Add to archive…” for all archive types (except zip)
“rar” date and folders are not stored
I just started using PA and wanted to say this program is awesome. I have been using winrar for years and this seems to be a much better program all around. I have been able to get much quicker archiving than winrar could ever produce. Thanks for such a great program!
Made som more tests with PACL 7.00 [May 11 2012] and noticed one small thing.
When running PACOMP without any parameters, no remainder pop up to tell the user that the program is unregistred. However if I run the PACOMP with parameters and a file to create the remainder will pop up.
This is inconsistant behaviour as
all have the pop up remainder to register the program when running it without any parameters.
It’s really not a big issue, just noticed that PACOMP don’t behave the same as the other program when running unregistred without any parameters.