-
-
Re: Explorer.exe Crash on right click
This appears to be happening again with the Power Archiver 2022 shell extensions.
When I have Use Explorer Shell Extensions enabled in Power Archiver Configuration and right-click on c:\Users\username\Start Menu, (hidden Junction file), File Explorer crashes.
I have version 21.00.15 (03/2022) 64-bit installed in Windows 10 Version 21H2 (Build 19044.1826).
-
In the latest version of PA, on W11 (latest build/SP) when you try to use the first level context menu - NOTHING HAPPENS (particularly when you do this from Downloads or Documents folders) - however I noticed that it DOES WORK when you use the context menu from the Desktop. Going to the second level context menu does work however.
-
PA 2023 22.00.08
Long time no seeing. So I start up the new year with a first problem : the virtual driver cannot be installed. Reason : it is missing in the Fast Ring PatchBeam Update Service…
Virtual driver PA 2023-01-28 152607.png
It seems a standard problem with new releases :-)
Can I have a link or can it be fixed. Thank you. CU later -
When the function for testing archives is invoked via the shell context menu (PowerArchiver > Test) then all the files in the archive get extracted to the current folder.
The test dialog reports as many errors as there are files in the archive but it fails to give any hint as to which files are supposed to be erroneous or what the nature of the problem might be. Comparing the extracted files to the originals shows no differences at all.
The .7z in question was produced with maximised compression settings in 7zip (taking forever but resulting in smaller archives than .7z produced by PowerArchiver with maximised settings). Therefore I wanted to see whether PowerArchiver can at least test .7z that it produced itself. Hence I had PowerArchiver convert a .pa with the same contents to .7z. There weren’t any errors reported but the resulting .7z contained fewer than half of the files contained in the .pa (137 of 366), so I scratched that test.
Performance is abysmal when testing via the context menu (e.g. almost 2 minutes for testing a .7z that 7zip tests in 4 seconds), but that is most likely due to the fact that the extracted files are written to disk. Testing the same .7z in the PowerArchiver GUI takes only 8 seconds but causes the mysterious appearance of a UAC dialog, as reported elsewhere.
The testing function is vital because PowerArchiver has a history of producing archives that it cannot unpack without errors or that do not conform to the respective file format standards (e.g. ZIP) so that other programs report them as erroneous.
The point of creating archives is that the files in them will most likely have to be extracted at some point. If the extraction cannot be guaranteed to produce correct results then the whole program is absolutely pointless. Actually, worse than pointless - it causes data loss and hence damage.
-
In PowerArchiver 2023 22.00.06 configuration, the option labelled “Start PowerArchiver 2023 Starter when my computer starts” seems to be redundant.
I am only allowed to change this option when PA Starter is disabled, and then it seems to be ignored.
When I enable PA Starter this option is forced to the enabled state.
I think it’d be good to remove “Start PowerArchiver 2023 Starter when my computer starts” completely. I’ve always found it confusing having both options.
Added later: However i don’t particularly want to use queue but I do like having the PAStarter icon in my tray area.
-
W10 Pro 22H2 - 64 -bit
PA 22.00.06 (PA 2023)
It has been the case with previous versions of PowerArchiver, but I had hoped that the latest might behave differently. Not so, I’m afraid.
I have, for various obscure reasons, created a few .pa archives, mainly in the hope that they will save me some more space. From time to time, I use the “Test” option to check that important archives are OK and uncorrupted.
With every .pa archive I’ve tested, the process runs through OK but then reports that there are errors. This is always the number of files in the archive e.g. if 11 files, then 11 errors reported.
In the .pa, I can:-
preview the files (usually PDF) extract some or all files and look at or use them convert the .pa to a .zip or .zipx archive, which then works fine and tests without errorsIs it the case that the Test routine isn’t designed for .pa archives, or is there another reason? Although the .pa seems to function properly, despite the test reporting errors, I would like to be sure that every .pa is OK and not “broken”.
Some of the .pas are quite old and produced with earlier PA versions (they are truly “archives”). If I extract all the files in the old .pa, create a new, fresh .pa and add back the files to that, then test the new, no errors (at least in the .pa I’ve tried this on) are reported. This would suggest a mismatch between old .pas and newer versions of PA itself.
-
Clipboard02.jpg
See the, supposedly, blank space where the green box is? It’s like that in Modern Light theme too. I can toggle it, but it’s missing text or shouldn’t be there I guess?
Thanks :)
-
Dear @Alpha-Testers and all of our users,
time has come for testing of PowerArchiver and PACL for macOS.
Please let us know here if you have Mac and can test latest builds.Features implemented:
PowerArchiver 2020 - tabbing, opening, extracting, adding, testing, favorite folders, support for multiple languages, opening via Finder, explorer mode, installer.
PACL 10 - support for most formats and features in Windows version.Upcoming: Tools such as archive converter, batch zip, multi-extract.
To start testing, please sign up here in this thread, and we will send you latest build.
thank you!
Ashampoo_Snap_Wednesday, November 20, 2019_12h54m56s_008_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h55m05s_009_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h55m14s_010_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h55m30s_011_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h55m39s_012_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h55m49s_013_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h56m00s_014_.png Ashampoo_Snap_Wednesday, November 20, 2019_12h54m43s_007_.png
76e97ab9-8d75-4175-9ce8-446500031f38-image.png
7-Zip better than PA 2011?
-
Hi, I just conducted a benchmark comparison test pitting 7-Zip 9.20 vs PA 2011 and I have noticed that archives created by 7-Zip are relatively small compared to the same archives created by PA 2011 with the same settings for both of them.
I used VLC Media Player (81.2 MB) as a test sample and here are the settings shown in the screenshots:
And here are the results:
7-Zip – 16.6 MB
PA 2011 – 17.4 MBAlthough the difference between the output file size is minor, it becomes more apparent when compressing 1 GB or more.
Could the lack of advanced options (Dictionary and Word size) in PA 2011 played a role in this discrepancy? And is there a way to get PA 2011 to match the output file size of its 7-Zip counterpart?
-
we both use different settings but overall difference should be literally in bytes or kb’s at max.
thanks for the report, we will be checking it out
-
there is possibility of 7z using some extra settings in later versions for stronger compression in ultra mode… max and others are the same… we will be checking it out.
-
we both use different settings but overall difference should be literally in bytes or kb’s at max.
thanks for the report, we will be checking it out
Well, there is another thing you might want to check into. I ran a benchmark test again, this time with five duplicates of a previously mentioned test sample totaling 406 MB (5 x 81.2 MB) and I changed the compression level from Ultra to Normal for both archivers. Note that when I set it to normal in 7-Zip, the dictionary and word size were automatically changed to 16 MB and 32, respectively. Here are the results.
7-Zip – 26.0 MB (00:01:23)
PA 2011 – 26.0 MB (00:01:59)Both of the output file size are the same despite the miniscule differences in bytes (see screenshots above). However, the time it took to compress them are strikingly obvious: 7-Zip was 36 seconds faster than PA 2011. Heck, I even changed the dictionary and word size back to the original (the default settings for Ultra) with the normal settings intact and it was still 7 seconds faster and resulted in slightly better compression ratios, 24.7 MB to be accurate.
All things said, I’m not sure why you used a different settings than the one used in 7-Zip, but I feel your choice of settings is in need of some kind of adjustment since it’s not quite up to par with 7-Zip’s settings.
I’m only bringing this up so you can improve the 7-Zip engine.
-
Well, there is another thing you might want to check into. I ran a benchmark test again, this time with five duplicates of a previously mentioned test sample totaling 406 MB (5 x 81.2 MB) and I changed the compression level from Ultra to Normal for both archivers. Note that when I set it to normal in 7-Zip, the dictionary and word size were automatically changed to 16 MB and 32, respectively. Here are the results.
7-Zip – 26.0 MB (00:01:23)
PA 2011 – 26.0 MB (00:01:59)Both of the output file size are the same despite the miniscule differences in bytes (see screenshots above). However, the time it took to compress them are strikingly obvious: 7-Zip was 36 seconds faster than PA 2011. Heck, I even changed the dictionary and word size back to the original (the default settings for Ultra) with the normal settings intact and it was still 7 seconds faster and resulted in slightly better compression ratios, 24.7 MB to be accurate.
All things said, I’m not sure why you used a different settings than the one used in 7-Zip, but I feel your choice of settings is in need of some kind of adjustment since it’s not quite up to par with 7-Zip’s settings.
I’m only bringing this up so you can improve the 7-Zip engine.
try with lzma and see what happens there.
-
one idea realted to this isto note that the 7zip engine is newer than the one in pa
Did you use the beta 7zip version by the way?
-
one idea realted to this isto note that the 7zip engine is newer than the one in pa
Did you use the beta 7zip version by the way?
I must admit i love the 7zip format it is my preferred compression technique.
But i dont use their application as i prefer PowerArchiver. Is the Beta 7zip any good? better compression by much? when can PA Adapt it?
-
the only option possible is to have 7zip as a plugin sing the 7zip engine so that when a beta version of 7zip comes out you can choose to use that engine to ensure the best possible and uptodate 7zip experience
-
@Sir:
I must admit i love the 7zip format it is my preferred compression technique.
But i dont use their application as i prefer PowerArchiver. Is the Beta 7zip any good? better compression by much? when can PA Adapt it?
compression should be exactly the same (or within 1%)… if it isnt, then it is an bug :-)
-
try with lzma and see what happens there.
Like lzma2, I got the same results with lzma under normal setting. The same is true for PA 2011 except the compression time was quite different.
7-Zip – 26.0 MB (00:01:23)
PA 2011 – 26.0 MB (00:01:29)Both archivers yielded the same size for both files, but PA 2011 took less time to compress it (30 seconds faster) though it trails 7 seconds behind 7-Zip. It seems to me that PA 2011 handles lzma better than lzma2 which should not be the case considering that there’s no real difference between lzma and lzma2 in terms of compression ratio, compression/decompression speed, or RAM usage. The only big difference in lzma2 is when taking advantage of the extra CPU threads. In fact, I just realized that PA 2011 with lzma2 enabled do not even utilize the full extent of my Core i7-860 processor. 7-Zip, on other hand, has no problems maxing out my quad-core setup (8 CPU threads) which finish in 36 seconds albeit at the expense of few extra MBs.
one idea realted to this isto note that the 7zip engine is newer than the one in pa
Did you use the beta 7zip version by the way?
No, I’m using the latest stable version (9.20) and unless stated otherwise, I assume PA 2011 is using this version as well.
-
It’s worth mentioning that the ZIPX format does make full use of my quad-core setup, thanks to “Multicore compression” option. I wondered why this option doesn’t exist for 7z format?
-
It’s worth mentioning that the ZIPX format does make full use of my quad-core setup, thanks to “Multicore compression” option. I wondered why this option doesn’t exist for 7z format?
it is due to the different engines - our engine for zip/zipx is our own and multicore optimized. For LZMA/LZMA2 we use 7zip engine.
What is happening right now with your issues is:
a. We didnt optimize Ultra settings in same way as 7zip - this should be simple fix in next release.
b. Devs turned off multicore in lzma2 since it would crash PA due to some issue with 7zip dll. We need to figure this one out.thanks for all the help.