I’m trying to backup the complete contents of a directory using:
pacomp64 -parcz T:\BACKUP.PA C:\STUFF
The contents of subdirectories of C:\STUFF isn’t getting backed up!
The sub directories are just stored as empty directories!
thanks for your help in getting my PowerArchiver CommandLine license (Re: License Code Not Working / Missing) and sorry for my late reply. I do check my spam folder regularly and couldn’t find a mail from support. Also, there was no mail in my backups or any mention of it in my email logs.
I have a question regarding my licenses in the hope you are able to help me:
While my account lists “PowerArchiver Select - lifetime free upgrades and support for PowerArchiver Toolbox English - Count 2”, this does not apply for PACL, which was included with my purchase. My account shows only PowerArchiver Select - 12 months of upgrades and support for PowerArchiver Command Line - Single User License.
Since PACL was included with PowerArchiver Toolbox, shouldn’t PACL also come with a lifetime license for 2 PCs?
Thanks for your help in advance.
PACL 9.00 Beta 2
What’s New since version PACL 7:Updated to PowerArchiver 2017 engine Fully unicode interface RAR v5 (v4) support PAE2 support
Latest format support and all the various engine updates done in PA 2017.
Full support for .PA format with many different options and switches.
Due to the support of new PA format and all the changes needed for that support, we decided to move up version number to PACL 9. This is purely cosmetical - companies who purchased PACL8, have PACL9 now added to their orders. Users who have free upgrades for PACL8, now have PACL9 added as free upgrade (Business users with active select (pro/tbx), all personal users (pro/tbx).
Since we are finalizing PA 2017, we can also now spend a lot more time on PACL9.
Please check your bugs, and check .PA support as well.
Thank you! @Alpha-Testers
My OS: Windows XP Home Edition, SP3
The version number and date of the program: PowerArchiver Command Line v9.00b [Feb 23 2019]
The program not extracts one self-extracting file.
How to reproduce the problem
Download the SFX file by link: install.exe
Copy the “install.exe” file into the same location as the program is located.
Go to the DOS prompt. Make your PACL location the default drive.
If it is on the E drive enter the command E: and press enter. Replace “E:” with the appropriate drive letter.
Enter command cd e:<path name> to go to the location where the program resides.
As a result, the “install” directory will not be created and no
files will be extracted.
The “install.exe” file may be damaged but if you use a program such as 7-Zip or PeaZip to extract the files, the extraction process is successful. I want the PACL to also unpack such a file.
This problem is very critical for me. I often come across this. I do not want to resort to using other compression program.
there’s a problem with PAComp and file names with a leading ".\ ".
That’s nowadays a problem, since PowerShell auto complete will complete a file test.zip in the current directory to .\test.zip.
The first command reports “All OK”, but test.7z is not created.
The second command reports an error, but the error message isn’t helpful at all. VSS doesn’t help anything if a program fails to write to a file. It’s for reading locked files… And the problematic file isn’t mentioned at all. By the way, there’s a typo, it should be “open”, not “opet”.
Only the third command (without ".\ ") works as expected.
The problem exists in the x86 and x64 version, it doesn’t matter if the archive already exists (updating) or not (creating a new archive).
PACL 8.00 Beta 1
Whats New:Updated to PowerArchiver 2016 engine Fully unicode interface RAR v5 (v4) support PAE2 support Latest format support such as improved ZIPX, ISO, etc, etc, etc.
Please test it against your existing scripts and let us know. There will be some features added in future release as well as more testing.
This is first release, please test. Thank you!
I’ve made changes to fix some problems with PAConv.bat:
1. Replaced the “” by () in the first two lines, so that it’ll work with command line arguments in quotation marks
2. Replaced deltree with rmdir, since deltree is unknown at least in Windows XP and later
3. Also replaced the del command, which left an empty $PATEMP$ directory with rmdir
4. Changed $PATEMP$ to “%TEMP%$PATEMP$.%time::=%”, so that no write privileges are needed in the current directory as the users Temp directory is used and that more operations will work simultaneous, as long as they are not started at the very same time.
5. Changed %n to “%~n” to allow parameters with spaces and quotation marks
Permission issue on ZIP file after using PACL in XP Mode
On my host system, I am using Windows 7 Enterprise 64-bit. It is fully updated. I have PowerArchiver 2010 Free (v11.63.12) installed. I also have the latest version of PACL (v6.01) installed.
So that I can still use some old 16-bit DOS programs, I have XP Mode installed. On it, I have PACL v6.01 installed as well (thought I DON’T have the windows program [PowerArchiver 2010] installed on it).
I also have the C drive of XP Mode mapped to the Z drive of my host machine, allowing me to access files from the XP Mode machine from a drive letter on my host machine.
Now for the problem–anytime I compress a file in XP Mode using PACL, I am not able to access it from the Host machine. Two examples: (1) if I open up the XP Mode drive in an explorer window of the host machine and double click on the newly created ZIP file, it will open PowerArchiver 2010, but the contents will be blank, (2) if I attempt to attach the newly created ZIP file to an email (in Thunderbird), I get a message saying, “You don’t have permission to open this file.”
I should point out that this seems to happen ONLY to files created with PACL (and only those created in XP Mode). I used to use PKZIP for DOS v2.50 to compress files from the command line. I gave it a try in XP Mode, and it allows me to do all of the above to which PACL created files are giving me issues. I also have used PACL on the host machine, and, again, no issues.
Any advice would be extremely appreciated!
what are the user permissions on those files that wont be opened? Can you change them by using file property in Windows Explorer?
Spwolf–you are a genius. My XP Mode is not joined to a domain, thus “Simple File Sharing” was enabled by default. As a result, I didn’t have a Security tab when looking at the properties for the shared drive. And it didn’t even occur to me to enable it until I read your post.
So I disabled “Simple File Sharing,” went to the Security tab for the shared drive, and changed the needed permissions. And it worked. Thank you.
Just curious, though, why would the lack of appropriate permissions affect ZIP files created with PACL but not, for example, those created with PKZIP for DOS?
probably for some compatibility reasons with old programs, I am not sure myself. But that was the first area I would look at… thanks!
I hate to bring this up again, but I’m experiencing the same problem in XP Mode again. I’ve figured out that when I change the security permissions, it effects only files already on the XP Mode hard drive, not those created after setting the permissions.
So, in other words, since I’ve already set the permissions to allow me access to the files, if I create a new file using PACL, I then have to set the permissions yet again to be able to access that file from the host machine. And I would have to do this after every new file I create.
I would normally think this is a Windows issue (since it deals with security and permissions); however, files created with PACL seem to be the only ones affected (not even ZIP files created with PKZIP for DOS are affected). So I’m hoping someone here would be able to shed some light on how to solve this.
I think I finally figured it out…
A friend of mine suggested the following for the security settings in XP Mode:
"Is inherited permission under security, advanced? perhaps it lost the inher. permissions and the rights aren’t “trickling” down. "
It worked. Yay!!!
basically user that accesses the drive, should be able to access files created by the “user” that is creating the files. I personally set it up so they use that is accessing the drive is same username as user on that XP Mode OS.
I dont think it is anything other than files being owned by another user. Something that application working in 16 bit compatibility mode might not set properly at all.
ah you figured it out… as we europeans would say, Super!