-
Configuration:
Powerarchiver 2021 20.00.73
Windows 10 Education 10.0.19042 Build 19042When extracting gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf.tar.xz , Powerarchiver wrongly thinks some .exe files have a length of zero:
98773b3b-65c0-48fa-8cd4-d081b2e0adee-image.png
Once extracted:
D:\Temp\Powerarchiver\gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf\bin>dir *.exe Volume in drive D is DATA Volume Serial Number is 0E12-BCA2 Directory of D:\Temp\Powerarchiver\gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf\bin 2020-11-20 07:10 PM 1,391,599 arm-none-linux-gnueabihf-addr2line.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-ar.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-as.exe 2020-11-20 07:41 PM 3,030,119 arm-none-linux-gnueabihf-c++.exe 2020-11-20 07:10 PM 1,389,293 arm-none-linux-gnueabihf-c++filt.exe 2020-11-20 07:41 PM 3,027,513 arm-none-linux-gnueabihf-cpp.exe 2020-11-20 07:10 PM 4,040,503 arm-none-linux-gnueabihf-dwp.exe 2020-11-20 07:10 PM 391,769 arm-none-linux-gnueabihf-elfedit.exe 2020-11-20 07:41 PM 0 arm-none-linux-gnueabihf-g++.exe 2020-11-20 07:41 PM 3,026,926 arm-none-linux-gnueabihf-gcc-10.2.1.exe 2020-11-20 07:41 PM 609,607 arm-none-linux-gnueabihf-gcc-ar.exe 2020-11-20 07:41 PM 609,607 arm-none-linux-gnueabihf-gcc-nm.exe 2020-11-20 07:41 PM 609,607 arm-none-linux-gnueabihf-gcc-ranlib.exe 2020-11-20 07:41 PM 0 arm-none-linux-gnueabihf-gcc.exe 2020-11-20 07:41 PM 2,165,533 arm-none-linux-gnueabihf-gcov-dump.exe 2020-11-20 07:41 PM 2,343,605 arm-none-linux-gnueabihf-gcov-tool.exe 2020-11-20 07:41 PM 2,450,233 arm-none-linux-gnueabihf-gcov.exe 2020-11-20 07:54 PM 9,605,899 arm-none-linux-gnueabihf-gdb.exe 2020-11-20 07:41 PM 3,028,997 arm-none-linux-gnueabihf-gfortran.exe 2020-11-20 07:10 PM 1,412,943 arm-none-linux-gnueabihf-gprof.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-ld.bfd.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-ld.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-ld.gold.exe 2020-11-20 07:41 PM 25,546,567 arm-none-linux-gnueabihf-lto-dump.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-nm.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-objcopy.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-objdump.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-ranlib.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-readelf.exe 2020-11-20 07:10 PM 1,393,083 arm-none-linux-gnueabihf-size.exe 2020-11-20 07:10 PM 1,392,464 arm-none-linux-gnueabihf-strings.exe 2020-11-20 07:10 PM 0 arm-none-linux-gnueabihf-strip.exe 32 File(s) 67,465,867 bytes 0 Dir(s) 1,002,422,431,744 bytes freeWhen the same archive is being extracted from a git bash session (after having installed git 2.30.1 for Windows 64 bit version from git-scm.com), the .exe files are extracted as expected:
xz -k -d gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf.tar.xz tar xf gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf.tar cd gcc-arm-10.2-2020.11-mingw-w64-i686-arm-none-linux-gnueabihf/bin ll *.exe -rwxr-xr-x 1 User 197121 1391599 Nov 20 19:10 arm-none-linux-gnueabihf-addr2line.exe* -rwxr-xr-x 2 User 197121 1421598 Nov 20 19:10 arm-none-linux-gnueabihf-ar.exe* -rwxr-xr-x 2 User 197121 2028927 Nov 20 19:10 arm-none-linux-gnueabihf-as.exe* -rwxr-xr-x 2 User 197121 3030119 Nov 20 19:41 arm-none-linux-gnueabihf-c++.exe* -rwxr-xr-x 1 User 197121 1389293 Nov 20 19:10 arm-none-linux-gnueabihf-c++filt.exe* -rwxr-xr-x 1 User 197121 3027513 Nov 20 19:41 arm-none-linux-gnueabihf-cpp.exe* -rwxr-xr-x 1 User 197121 4040503 Nov 20 19:10 arm-none-linux-gnueabihf-dwp.exe* -rwxr-xr-x 1 User 197121 391769 Nov 20 19:10 arm-none-linux-gnueabihf-elfedit.exe* -rwxr-xr-x 2 User 197121 3030119 Nov 20 19:41 arm-none-linux-gnueabihf-g++.exe* -rwxr-xr-x 2 User 197121 3026926 Nov 20 19:41 arm-none-linux-gnueabihf-gcc-10.2.1.exe* -rwxr-xr-x 1 User 197121 609607 Nov 20 19:41 arm-none-linux-gnueabihf-gcc-ar.exe* -rwxr-xr-x 1 User 197121 609607 Nov 20 19:41 arm-none-linux-gnueabihf-gcc-nm.exe* -rwxr-xr-x 1 User 197121 609607 Nov 20 19:41 arm-none-linux-gnueabihf-gcc-ranlib.exe* -rwxr-xr-x 2 User 197121 3026926 Nov 20 19:41 arm-none-linux-gnueabihf-gcc.exe* -rwxr-xr-x 1 User 197121 2165533 Nov 20 19:41 arm-none-linux-gnueabihf-gcov-dump.exe* -rwxr-xr-x 1 User 197121 2343605 Nov 20 19:41 arm-none-linux-gnueabihf-gcov-tool.exe* -rwxr-xr-x 1 User 197121 2450233 Nov 20 19:41 arm-none-linux-gnueabihf-gcov.exe* -rwxr-xr-x 1 User 197121 9605899 Nov 20 19:54 arm-none-linux-gnueabihf-gdb.exe* -rwxr-xr-x 1 User 197121 3028997 Nov 20 19:41 arm-none-linux-gnueabihf-gfortran.exe* -rwxr-xr-x 1 User 197121 1412943 Nov 20 19:10 arm-none-linux-gnueabihf-gprof.exe* -rwxr-xr-x 4 User 197121 2572182 Nov 20 19:10 arm-none-linux-gnueabihf-ld.bfd.exe* -rwxr-xr-x 4 User 197121 2572182 Nov 20 19:10 arm-none-linux-gnueabihf-ld.exe* -rwxr-xr-x 2 User 197121 4550029 Nov 20 19:10 arm-none-linux-gnueabihf-ld.gold.exe* -rwxr-xr-x 1 User 197121 25546567 Nov 20 19:41 arm-none-linux-gnueabihf-lto-dump.exe* -rwxr-xr-x 2 User 197121 1404945 Nov 20 19:10 arm-none-linux-gnueabihf-nm.exe* -rwxr-xr-x 2 User 197121 1531656 Nov 20 19:10 arm-none-linux-gnueabihf-objcopy.exe* -rwxr-xr-x 2 User 197121 1991350 Nov 20 19:10 arm-none-linux-gnueabihf-objdump.exe* -rwxr-xr-x 2 User 197121 1421598 Nov 20 19:10 arm-none-linux-gnueabihf-ranlib.exe* -rwxr-xr-x 2 User 197121 1163376 Nov 20 19:10 arm-none-linux-gnueabihf-readelf.exe* -rwxr-xr-x 1 User 197121 1393083 Nov 20 19:10 arm-none-linux-gnueabihf-size.exe* -rwxr-xr-x 1 User 197121 1392464 Nov 20 19:10 arm-none-linux-gnueabihf-strings.exe* -rwxr-xr-x 2 User 197121 1531656 Nov 20 19:10 arm-none-linux-gnueabihf-strip.exe*The same archive file does extract properly under a native Linux Ubuntu 20.04 system, or under Windows 10 using the WSL2 Linux subsystem using xz and tar.
-
Its a long time since people reported bugs like converter bug still no fix yet
-
Hi,
I just saw, that on the Website, PowerArchiver 2021 20.00.73 is advertised as latest version. (Actually, the downloaded version says, it’s 20.00.70 in the about dialog)
But it still comes with the “red icon set” for preview versions and has some known unfixed bugs, as I read here.Is it sufficiently stable to be used on production systems?
Kind regards
-
-
Hi I recently bought PowerArchiver and found some bugs and issues that I hit testing some of the features out.
If you are doing a backup and on the compression options screen its default is compression format is PA with no option to change disk spanning. If you change to 7-zip you can change disk spanning. If you change the disk spanning then move back to PA format the field for disk spanning disables but the option stays set to what you changed it to. When you do a backup it will use PA with files spanning but PowerArchiver says that its not a valid format when you open it. If PA can’t really do file spanning then this screen is allowing it.
I have attached an image where the progress bar is in the middle of the CD/DVD/BD Tools screen.
alt text
I have a 7-Zip file I created using the backup tools doing an increment backup. It opens and extracts just fine but if you using the Test option PowerArchiver locks up. Link to file: Backup-2021-02-05-20-35-36 TEST LOCKUP.7z
On any Zip/PA/7-Zip process the pause and cancel buttons do not work. You have to hard kill the entire application to get out.
-
There would be many of us with Intel Processors.
and they have their own optimized zlib algorithm, which can result in more efficiency if used combined with their hardware processor.
Reference:
https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/zlib-compression-whitepaper-copy.pdfCan we get the same Functionality Under Hardware Acceleration Feature?
Zlib is not the only feature that intel has included with their processor, there’s many, which if combined can result in efficient and better compression ratios.
-
Hi,
After the batch archiving is complete, and if I click on whitespace of the PA app, I get this error.
PA Batch.png
I did check for ongoing process and ensured no archives were corrupt, It seems like activity did complete successfully but the error is shown for no reason, and only after clicking the whitespace.
Please see if this can be removed.
-
I’m using the Kaspersky Total Security.
I have configured PA as exclusion as followed:
PA Exclusion.png
and also is set us trusted application
PA Trusted Application.png
Scenario:
My Antivirus likes to scan for everything, and it’s safeguarding behavior is to prevent the access to the file until the file is properly scanned for.
The issue:
PA when losses the access to file, it is stuck, consumes Resources, and never completes the process or throws any error
Recommendation:
PAStarter should also work as PAMonitor:
There should be a monitoring process, at least if I’m using queuing feature, that should check for never ending compression processes and terminate them so the queue can be little bit automated.Also,
There should be multiple attempts at retrying if PA loses access to or is denied, instead of having to see process was stuck for longer duration.Or, better, save the parameters I used for keeping the files in compression, and automatically restart the whole compression process after termination the same, of same folders and files set, this should happen in case if compression was stuck.
-
If you use Queue Feature, you are not saving on space, you are just squeezing less.
Here’s explaination:
https://youtu.be/XcxG2wxyink
I did test the same on multiple files, and of different types.
It does have large difference for each large file you are trying to squeeze.
Folders with multiple files, just have no benefits if you use Queue Feature
-
Hello!
I am using the portable version of PA2021. After switching from build 58 to 73 I have problems with the color-scheme:
While 58 behaves like expected and showed everything in light or dark colors according to the settings, 73 always shows the lower part of the window in dark colors, no matter whether I select automatic, light or dark.
This happens on a clean installation of 73 as well as on an update from build 58. I have attached two images generated on the same machine at the same time with the same settings. The upper shows build 73, the lower 58. Is it a bug or some changed setting I miss?
Thanks for help!
A.BorquePA2021_73.png PA2021_58.png
-
Hello,
PowerArchiver Command Line 7 support file greater than 2 Go ?
Thanks
-
If you have tabbed archive browsing(reuse same window for all archive opening)
and if you open two archives, and right click on older one to view properties it will only show of the recent archive that was opened, on all tabs/archivesupgraded to 20.0.73
-
Hi.
I currently own the PowerArchiver Select - lifetime free upgrades and support for PowerArchiver Toolbox English license.
This license is active on 1 device. Does the license allow me to activate PowerArchiver on a second device that I own? Or do I need a separate license for that?
Thank you ! :)
-
Hello!
While the installable version of PA 2021 has already received two updates and is at version 20.0.73 the portable version still remains at the initially released build 58. Are there plans to update that version, too?
Thanks for a reply! -
I’ve been dealing with an intermittent explorer.exe crash for 5-6 years now. It happens randomly and will usually occur multiple times within a single session of an hour or two on my machine when manipulating files through Windows Explorer. explorer.exe is the only thing that ever crashes, so it’s not hardware IMO. I’ve done all hardware diagnostics and RAM is good. I’ve even swapped out motherboards with different brand and even the exact same one and it still crashes. sfc /scannow indicates system files are fine. I’ve done multiple reinstalls of the OS with no positive results. This crashing has happened on Windows 7 64-bit and Windows 10 64-bit. It seemed to get more frequent with Windows 10 after upgrading last year. I’ve also been using PowerArchiver throughout that time period (upgrading over time with new releases). I recently disabled all non-Microsoft extensions via ShellExView and saw no crashes for about 10 days, which is really unusual. I turned back them all back on after 10 days and saw another explorer.exe crash within the hour. So I disabled all 32-bit extensions and saw another crash. Following that I disabled all the PowerArchiver shell extensions and haven’t seen a crash after a day of heavy usage manipulating files within Windows Explorer, which doesn’t happen for me. The crash dumps I’ve captured don’t seem to indicate PowerArchiver is involved but I have a hunch it has something do with PowerArchiver shell extensions. The system even feels smoother with the PA extensions disabled. Windows 10 reliability monitor always has the same type of problem:
Description Faulting Application Path: C:\WINDOWS\explorer.exe Problem signature Problem Event Name: BEX64 Application Name: explorer.exe Application Version: 10.0.17134.165 Application Timestamp: 4031a9f8 Fault Module Name: StackHash_e78e Fault Module Version: 0.0.0.0 Fault Module Timestamp: 00000000 Exception Offset: PCH_8D_FROM_ntdll+0x000000000009AA54 Exception Code: c0000005 Exception Data: 0000000000000008 OS Version: 10.0.17134.2.0.0.256.48 Locale ID: 1033 Additional Information 1: e78e Additional Information 2: e78e327659b46c9a0c6916396b253cbf Additional Information 3: cebf Additional Information 4: cebf952c5db535ae7880488aafce55d9 Extra information about the problem Bucket ID: 1a57e4e784fbc735c231c68bd88581a9 (1311047270476906921)I know this is a very nebulous explanation but is there any way to link this up to PA shell extensions as the cause? I can provide the crash dumps and additional information if necessary.
-
When you select “Deflate (.zip, compatible)” as the method, it still converts the archive to a ZIPX format.
-
Would like to see uha archives supported compression as well as extraction. I use this all the time and it is a very good compression format
-
In windows 10 you can right-click and select send to and the compressed zipped folder and the zip folder will contain the name of the last selected file.
Does PowerArchiver have a similar function?
Tom
-
Converting an archive to .zip (using both the “Deflate (.zip, compatible)” and “Store” compression methods) always creates a .zipx file instead.
pa-convert-zip-1.jpg
pa-convert-zip-2.jpgUsing the “Store” method sometimes creates a .zip file; I have seen it happen just now, but I cannot reproduce it.
-
patchbeam a waste of time never updated with latest version
Filename extensions changed ??
-
I have a .tar.gz from a CPanel full backup, and there are quite a number of files within the archive, that Powerarchiver “reports” as having a different filename extension.
The problem is not with Cpanel, or with the actual archive, because my web host provider has been able to extract the full contents of the archive, and all the filename extensions are okay.
Powerarchiver is listing the files as having different filename extensions, and therefore when I extract the archive locally, there are many files (337 out of 4,373 files) with invalid extensions.
The extensions are changed as follows:
.GIF –-> .GIF0000444
.HTML —> .HTML0000444
.php ----> .php0000444I’m using version 10.01.03, but actually I have noticed this problem with earlier versions, however as it was only a few files, I simply renamed them.
It appears the bug in Powerarchiver is somehow referencing the filename permissions (444) and appending it to the filename extension.
Peter
-
I just opened the same archive with “7-Zip” and the filename extensions are okay.
-
Hmm… sounds familiar
Is it this problem resurfacing? :(
http://www.powerarchiver.com/forums/showthread.php?t=854 -
Thanks for that link. It sure does look like a very similar problem. :(
When I extracted the tar.gz locally, PA even created this folder
\public_html***\thumbs\0000755\
and there is definitely no such filename on the website, I just checked. The permissions on the path “thumbs” is 755 though, so the bug seems ‘constant’ to some degree, appending the file permissions, but seems to be doing it quite randomly (which I guess contradicts what I said about being ‘constant’).
I used both PA and 7-Zip to extract the archive, then used beyond compare to do a binary comparision of all the files, 4006 match and 341 are different, having filename extensions as explained in the first post.
The file sizes and timestamps are exact though, in the Beyond compare display, it’s just the file extensions that are messed up.
Bit of a problem alright.
-
Hmm… sounds familiar
Is it this problem resurfacing? :(
http://www.powerarchiver.com/forums/showthread.php?t=854No it isn’t. I cannot reproduce that problem in 10.01.03
using the “boost” sources (9378 files). -
When I extracted the tar.gz locally, PA even created this folder …
Can you try creating the backup with PA (tar.gz) as a test to see if the problem still occurs?
-
Can you try creating the backup with PA (tar.gz) as a test to see if the problem still occurs?
Yes, I created a tar.gz with PA on all the archive files, and I used the ‘correct’ files, that is, those with correct filename extensions.
PA has even messed that up, lots of weird filename extensions like:
H0000002
HT0000002
HTM0000002
HTML0000002
HTML444
P0000002
PH0000002
PHP0000002
PHP00444
PHP0100444
etc,etcI also used the same files to create an archive with a ZIP and a 7Z extension, and there are no strange filename extensions. Seems it is only happening with .TAR.GZ files, and yet a Linux ‘tar’ program plus the (freeware) 7-Zip software were both able to view the contents correctly, …. but not PA. :(
-
Something similar here
-
How do I log this as a bug please ?
-
This is getting ridiculous, I just created an archive (.tar.gz) with 2 files in it, and both have weird filename extensions.
Both these files had long filenames; does PA have any problems in that area ? This thread - http://www.powerarchiver.com/forums/showthread.php?t=1302&highlight=long+filename seems similar.
Looks like I use “7-Zip” until this is sorted out. :(
-
This is getting ridiculous, I just created an archive (.tar.gz) with 2 files in it, and both have weird filename extensions.
Both these files had long filenames; does PA have any problems in that area ?
What do you mean by “long”? How long are your path/filenames (how many characters)?
Can you provide the test file you created?How do I log this as a bug please ?
Well, spwolf and Ivan are the developers/ConeXware representatives - both check these forums regularly, you may assume that when they see this they will take on the internal “bug reporting/fixing”.
However, you could also create a premium support request if you want more “direct/personal” access. Just click on the Support link on the ribbon bar at the top of the forums.
-
What do you mean by “long”? How long are your path/filenames (how many characters)?
By ‘long’ I meant the filename itself is 28 chars, then add the period, then the file extension of ‘tpl’ in this case, and we have 32 just for the filename, … so that is ‘long’.
The path/filename are 115 bytes in total.
Can you provide the test file you created?
Possibly, I’d have to be certain the archive doesn’t contain any confidential info, it is for a website after all.
Thanks for the info on bug reporting, it’s not ‘super urgent’, so I will wait and see if one of the developers replies to this thread.
Thanks for your help. :)
-
By ‘long’ I meant the filename itself is 28 chars, then add the period, then the file extension of ‘tpl’ in this case, and we have 32 just for the filename, … so that is ‘long’.
The path/filename are 115 bytes in total.
Well, 32 char filename shouldn’t be the problem.
However 115 path/filename may be - in the thread you linked to
@spwolf:PA can currently compress correctly TAR path+filename of around 110 characters - although it should be able to uncompress up to maximum under Windows.
So that maybe the problem with your simple case.
Although, I don’t know if things have changed since 2005.
-
However 115 path/filename may be - in the thread you linked to
Okay, but that was dated 11-07-2005, surely PA has been improved since then ?
Also, the total of 115 I gave included the full pathname/filename source, but if I deduct the path length from were the source files are, it is 12 less, so total 103. That is, the total pathname/filename in the actual archive is 103 chars. This relates to an archive that PA created, where the filename extension is corrupt.
Also …. from the other thread
how do you mean strange abbrevations? Keep in mind that windows file system limit is 256 characters, everything above that will simply not get extracted properly and probably create small havoc in Windows (wont be deletable by Windows Explorer).
Yet I just totalled up the path/filename that PA had extracted from a tar.gz and where the filename extension is ‘corrupt’ and the total length us 140 bytes, way less than 256.
-
There are two seperate/different limits being discussed…
When PA creates the TAR file (compression) the 110 char limit is for the complete path/filename length (so you cannot subtract filename to get below 110.
When PA extracts from a TAR archive (created by another application) it should only be limited by OS - this is the 256 limit.
So the compression name length limit may explain the problem you recreated - when creating the TAR using the two sample files.
However, it does NOT explain the problem you encounter when extracting the other file (created by Cpanel ?) - this is now a seperate problem.
Unfortunately, we “know” this was fixed in PA 9.5; but maybe further changes re-introduced the extraction problem :confused:
We will have to wait for spwolf or Ivan to confirm I’m afraid.
-
Hi,
can you attach example file? Just make it as small as possible.
thank you!
-
Having tried a few different things, decided to set the config. to ‘default’.
Tried the compression again, and the filename extensions are okay, but the pathname is not correct for uploading to the website.
I always need to have the option “use normal relative path” checked, to make the pathname ‘valid’ for uploading.
So, is this a ‘clue’ to the problem ?
Under PA settings:
-Config
–-misc
------use normal relative path-
When checked, file extensions are messed up
-
When unchecked they are okay, but the pathname is not ‘suitable’.
I can re-arrange folders locally so that the correct pathname is included as the first one (highest), …BUT I think the only way I can get ‘empty paths’ into an archive is to have this option set on (checked). :(
This is only a small test, with those 2 files, but they are part of a substantial (path) heirarchy.
Just tested a considerable number of files (3250) with the option “use normal relative path” unchecked, and all the filename extensions are okay. Now I can see the full pathname/filename for one of these is 91 chars. If I include the “full” source pathname/filename, it is 149 chars.
Have now used the same files to create an archive, with the option “use normal relative path” checked, and the filename extensions are messed up. Even with the additional pathname added, it is still only 103 chars
So, could that option be the cause of the ‘bug’ ??
-
-
There are two seperate/different limits being discussed…
When PA creates the TAR file (compression) the 110 char limit is for the complete path/filename length (so you cannot subtract filename to get below 110.
Depends if the limit includes the “full” path/filename ‘source’ or not.
When ‘adding’ a path to an archive, is the path/s above that path, included in the limit ??
When PA extracts from a TAR archive (created by another application) it should only be limited by OS - this is the 256 limit.
Again, does the 256 limit only include the pathname shown in the archive, or the “full” pathname to where the destination files are uncompressed/extracted ??
Neither of these “limits” are clear.
However, it does NOT explain the problem you encounter when extracting the other file (created by Cpanel ?) - this is now a seperate problem.
I don’t see that as a seperate problem. The file created by Cpanel ‘backup’ checked out 100% okay on the Linux machine, using 'Tar" command. It also checked out okay using “7-Zip” on Win XP pro, BUT PA failed to read many of the filename extensions correctly.
That is exactly the same problem as PA being unable to create correct filenames.
In both cases, the problem only occurs in PA. :D
-
can you attach example file? Just make it as small as possible.
I can already see from Archive files that the information contained in the archive would compromise our website security.
It’s a bit like someone asking me for the keys to my house; I’m sure you understand. :)
I could send you (privately) these 2 files, and supply the directory structure I have here. If that was setup on a Win xp pro box, with the same version of PA, all things being equal (and config settings the same), the ‘problem’ should be able to be replicated.
-
can you attach example file?
I have sent a PM, with all the details needed to create the 2 files, plus replicate the same local directory structure I have.
-
My understanding of the limits are:-
@peterr:Depends if the limit includes the “full” path/filename ‘source’ or not.
When ‘adding’ a path to an archive, is the path/s above that path, included in the limit ??
When compressing, the limit is the information to be stored in the archive (creating the TAR file).
@peterr:Again, does the 256 limit only include the pathname shown in the archive, or the “full” pathname to where the destination files are uncompressed/extracted ??
It is an OS limit so must include “everything” - not just the archive contents.
@peterr:I don’t see that as a seperate problem. The file created by Cpanel ‘backup’ checked out 100% okay on the Linux machine, using 'Tar" command. It also checked out okay using “7-Zip” on Win XP pro, BUT PA failed to read many of the filename extensions correctly.
I wasn’t suggesting that the archive was in any way corrupt, but that the decompression by PA is incorrect.
@peterr:That is exactly the same problem as PA being unable to create correct filenames.
In both cases, the problem only occurs in PA. :D
No, I believe the "problems are different because of the different limits when compressing and decompressing.
If the 110 limit is still present in the TAR engine - then when exceeding the 110 limit, PA creates an incorrect archive. So the problem appears after decompressing but is “inherent” in the archive - would also appear with other decompressing utilities.
With a correct archive (from another application), the decompression problem has a different cause in PA - even if the result is the same in both cases. It is this case that may need an example archive!!
Still, I’m confident Ivan will be able to “sort it out” :D
-
If the 110 limit is still present in the TAR engine - then when exceeding the 110 limit, PA creates an incorrect archive. So the problem appears after decompressing but is “inherent” in the archive - would also appear with other decompressing utilities.
Not too sure what you are saying here, but I think you mean if PA was used to compress the tar.gz, and incorrect file extensions are in that archive, then other decompression utilities would also show the (incorrect) file extension.
Yes, of course.
Found some info on path lengths at Naming a File …
In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A path is structured in the following order: drive letter, colon, backslash, components separated by backslashes, and a null-terminating character, for example, the maximum path on the D drive is D:<256 chars>NUL.
I can only get to 247 as the max, after that an error message.
Just why there is a 110 limit I don’t know though, if it was a Win API limitation, then other archiving tools (e.g. “7-Zip”) would demonstrate the same problem I’m experiencing. However 7-Zip compresses the same folder without the incorrect filename extensions.
-
Just used “PeaZip” to create a tar.gz, using the same path/folder to add, the filename extensions are valid.
Also, just tried PACL, and it created the archive correctly.
-
I have sent a PM, with all the details needed to create the 2 files, plus replicate the same local directory structure I have.
thanks - we will check it out and see if we have any questions.
We didnt mean for you to send confidential data, you could have re-created same filename in same folder and that should have created same error… this will work too.
thank you!
-
thanks - we will check it out and see if we have any questions.
Okay thanks. I guess seeing the command line versions of PA work, I could use ‘pacomp’ and ‘paext’ in the interim period.
Thanks. :)
-
Something else that PA is doing with archives I created, with the extension .tar.gz
It makes additional paths in the archive, the paths are not on my local system at all, the archive has all these additional paths , named with a backslash ??
There were 15 additional paths, in the last archive I created, unfortunately I didn’t see the ‘garbage’ until the archive was used to load part of a website.
Of course when viewing an archive in ‘flat’ mode, only files are shown, so no pathnames appear. When viewing in Explorer mode, with the ‘2 window’ view, I could then see the additional paths.
There were 1635 files and 172 folders in the path that was archived locally. However the archive added 1635 files, and 187 folders/paths, the extra 15 wouldn’t even display properly when viewing the archive, but they sure made a nice mess of the website. :(
-
OK, just done a quick test.
3 files with 100, 110 and 115 chars in filename.
Each has “txt” extension (so length is 104, 114 and 119). Files are in sub-Folder with 16 char name.Create Tar with PA (no paths stored) - corruption occurs with all three filenames !!
Create Tar with 7-Zip (relative path stored)- PA displays and extracts this correctly (including pathname).
Note: no Gzip compression - this is simply TAR.
-
Thanks for doing that test. I also found if I used ZIP compression, the archive was okay.
-
Yes, the problem is with TAR compression.
Further tests show that even 100 chars corrupt.
The maximum length that TARs OK in PA 10 seems to be 99 chars (not 110 as suggested by other thread). -
The 99 max seems to indicate a V7 version of TAR, from a few search results here
-
With you guys doing all the work, there is nothing else for us to do…
;-)
-
With you guys doing all the work, there is nothing else for us to do…
:D
It seems the length limitations is the version of tar that PA must be using. Any chance of going to another version of the code that uses tar files ?? ;)
-
With you guys doing all the work, there is nothing else for us to do…
;-)
Except, analyse why the decompression/extraction failed from the Cpanel backup - that bit has me :confused:
-
Except, analyse why the decompression/extraction failed from the Cpanel backup - that bit has me :confused:
I just used PAEXT to extract that Cpanel backup, and there were hundreds of filename extensions messed up, so …
1. Both PA and PAEXT result in the same type of errors.
2. Using “7-Zip” on the same archive, no strange filename extensions at all, all the files are okay.
The code that is used in PA and PAEXT isn’t able to extract all the files correctly, whereas “7-Zip” is able to, … it’s a software thing. :)
-
Any idea when this bug will be fixed please ??
-
we are working on PAOP beta 2 right now, and then we will move to PA 2007 10.02
thanks!
-
we are working on PAOP beta 2 right now, and then we will move to PA 2007 10.02
thanks!
Okay thanks, I don’t know what PAOP is, I checked in my ‘PACL’ folder, but it isn’t there, I thought it must be a command line tool.
Will version 10.02 include the fix for the ‘extra paths’ problem as well (compressing files for an archive of .tar.gz extension, there has been additional paths found in the archive, with a pathname of ‘backslash’) ?
Thanks,
Peter
-
PAOP (Power Archiver Outlook Plug-in)
-
we have no idea what will it include until we start working on it :-).
-
Yes, the problem is with TAR compression.
Further tests show that even 100 chars corrupt.
The maximum length that TARs OK in PA 10 seems to be 99 chars (not 110 as suggested by other thread).Testing with PA 10.10.08
TAR (tarred)
90 (including .txt extension) chars OK
98 (including .txt extension) chars OK
100 (including .txt extension) chars OK
106 (including .txt extension) chars NOT OK- Displays OK but error when extracting
-
Sorry, that was misleading.
There is something strange going on -
Create a test Folder containing filenames of different lengths
I used 7 files (98 chars to 105 chars).
Length of 103 was correct.
98 to 102 were corrupted to be 103 chars (4, 44, 444, 0444, 00444 was added to extension .txt)
104 and 105 were corrupted by addition of the string “0000002” to the extension (both files).
:eek:So the result was
a) {longfilename}.txt00444
b) {longfilename1}.txt0444
…
…
c) {longer filename}.txt0000002
d) {longer filename1}.txt0000002
:confused: -
we have no idea what will it include until we start working on it :-).
I see 10.1 beta is out.
At this stage, do you know if 10.1 final will include the bug fixes for …
1. The filename extension problem as explained in this thread.
2. The “additional pathnames” bug/problem.
Also, thanks to Terry for doing some more testing. I was about to download a website backup toay, and then remembered about this filename extension problem with .tar.gz files. :(
-
The website backup was uncompressed to a local path, and there was a ‘mix’ of file extensions that ended in …
0000444
0000644I went and checked on the website, and it does match the file permissions (Linux box as server), so if that is of any help ?
In one path that was uncompressed/extracted, I can see where the ‘limit’ is. The pathname is 110 chars, including the volume number and all backslashes, and the filename extension has only been changed for 3 files in that path. Here is an example of one file that has no change to the extension, and one file that has the extension changed, as follows:
daily_usage_200610.png –-> daily_usage_200610.png
hourly_usage_200610.png --> hourly_usage_200610.png0000644The one extra character (the difference between ‘daily’ and hourly’) blew the limit.
The total size, of the file, at the “max” (daily_usage_200610.png), including full pathname is 132 bytes.
HTH
-
I just installed the latest PA, version 10.10.10 and this filename extension problem still exists. :mad:
I didn’t restart after the install, there was no message to do so.
-
I just installed the latest PA, version 10.10.10 and this filename extension problem still exists. :mad:
I didn’t restart after the install, there was no message to do so.
yeah, this will take longer since we have to add support for longer file+path in tar files… we had some priority fixes for 10.1
-
-
this will probably make it into 10.2, working on it now…
-
Thank you. :)
-
And it did :-).
Please check with Beta 4:
http://www.powerarchiver.com/test/release10/powarc1020.exePlease let us know if this fixes this issue as soon as you can.
thank you!
-
The filename extension problem still exists. :(
Also, when I extracted the archive, in addition to it creating the main pathname and all files and paths underneath that, it also created some other weird pathname, with 19 folders and no files when extracted.
The archive was large, PA is reporting 5032 files, 625 directories and 13,476,762 bytes.
-
can you send us the archive so we have it for testing? Just compress it with 7zip (tar file itself) and upload it to some free uploads site? Is that ok?
That would be very helpful….
thanks!
-
can you send us the archive so we have it for testing? Just compress it with 7zip (tar file itself) and upload it to some free uploads site? Is that ok?
Sorry, no can do, it’s a website backup and has a lot of confidential files in it.
I also used PACL to extract the same archive, guess what, same results, that is, lots of files created with the filename extension changed. This didn’t happen before with PACL, at least I don’t think so ??
I did a binary compare on the PA extract compared with the PACL extact, all files matched, but PA didn’t create a number of paths where there were no files, … sound familiar.
I may try some other archive tool tomorrow, on the archive.
Once again, the ‘pattern’ of the filename extensions is that the (cmod) permissions from the website, has been appended to the fiename extension.
Looking at one file that has had the extension changed, the pathname is 133 bytes, and the filename plus extension is 18 bytes, that makes 152 if we add the extra backslash.
The filename, plus extension is meant to be 11 bytes (modinfo.php), and there is another file in the same path that is a total of 10 bytes (index.html), which hasn’t had the extension name changed.
See attached screen dump of that path.
Also when I open the archive, PA seems to be showing the file extensions incorrectly, that is, the same as the screen dump.
-
cant you compress non-confidential parts of the website and send them over? I am sure you can recreate same behaviour without using files that you dont want to send us… 1 file is enough.
thanks!
-
The archive is automatically created from cPanel, I just hit the “create full backup” button.
I will see about trying to create an archive of ‘parts’ of the site manually, but please don’t hold your breath. :D
-
what about just deleting parts of the archive that are confidential and leaving few files that are fine? you can send it to us at support so it wont be for public viewing…
thanks
-
I’m not about to sort through 5032 files, and remove all the confidential ones.
As I said, …. it will take a while.
-
Have sent you a test archive. :)
-
Installed version 10.20.17 , and unfortunately, this problem is now worse. :confused:
Instead of just a few files that had the filename extension changed. there are now over 80 files (same archive used for testing), and the ‘filename’ (including the extension) has now been truncated. I checked 5 files, and they are all truncated at 145 bytes (includes full pathname and extension).
What is strange, is that when I shortened the length of the path used to extract, exactly the same problem occurred, that is, the same number of filenames are corrupt.
I would have thought decreasing the size of the (full) pathname, would have resulted in less errors found in the filename.
When I increased the size of the (full) pathname, and did the extract again, the filenames are now truncating at 151 bytes (145 + 6).
There don’t appear to be any filename extensions changed this time, just the truncation problem, but the problem is not consistant with the pathname length, and the same filename results, irregardless of the pathname length.
Here is an example, showing the correct filename, total size is 146 bytes …
F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_filepath.php
======
When the full pathname is increased in size by 8 bytes, the filename is truncated at 145 bytes …F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_fil
When the full pathname is increased in size by 6 bytes, the filename is truncated at 151 bytes …
F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_fil
When the full pathname is decreased in size by 22 bytes, the filename is truncated at 129 bytes …
F:\temp\powerachiver\….\class\smarty\internals\core.assemble_plugin_fil
In all cases, the same filename results, a truncated name, and in all extracts, exactly the same number of errors have occurred (approx. 80 files with filenames truncated).
‘spwolf’ has the same test archive, and will be able to see what the extract is doing.
When the archive is being viewed, the filenames appear to be okay, it is just some weird problem with the extract. :confused:
-
Please try with .21 from our website and see what happens.
thanks
-
Installed .21 , and ran the extract again, … same problems unfortunately.
Just extract the test archive I sent, and you will see where filenames have been truncated. :(
-
Has there been any progress on fixing this bug please ??
-
Try 10.21 RC 1 from our site and see if it works.
-
Try 10.21 RC 1 from our site and see if it works.
Can you supply a link please.
Also, this bug was reported over 6 months ago. I’d really expect it to be fixed by now, and not have to rely on “user testing” of new releases, especially when I went to the trouble of creating a website with various files, then created a website archive, and sent it to PA tech personnel, so they can test it.
-
did you use RC1? (10.21.xx) or 10.20.21?
:-)
Check RC1 from download page please.
-
Have downloaded and installed the RC1, thanks.
I have only checked a few files, especially the ones that were noted in the earlier post, and they are now okay.
Will create a larger archive and extract that, and then advise.
Thanks. :D
-
:-)
-
Well, the filename extensions seem okay, plus the filenames (and paths) look okay, but the modified time of the files don’t seem to reflect what the timestamps should be (I will have to look more into that).
Also, for some reason, PA displayed a “ghost” folder, one that isn’t on the website, called “the.same.host.name;”, see screen dump.
-
Two other minor annoyances with the interface, is that when using the “2-pane” view, the folders are not sorted, makes it a real pain for navigation (see screen dump).
Also, there needs to be a horizontal scroll bar added to the left hand pane/window, as often the 'folder depth" is more than the width of the left hand window, and therefore, folder/path names cannot be seen (see screen dump).
-
Yes, timestamps of the extracted archive are definitely a problem. Will have to look into it further, and then advise. :(
-
Two apologies. :o
Also, for some reason, PA displayed a “ghost” folder, one that isn’t on the website, called “the.same.host.name;”, see screen dump.
PA displayed that folder correctly, I ran the archive through “tar”, and the folder was there, fortunately on a PA extract, it just ignored the folder name.
Yes, timestamps of the extracted archive are definitely a problem. Will have to look into it further, and then advise. :(
I was baffled by the timestamps, because in some cases, the date (day) was different to the file date on the server.
Took me a while to realise it was adjusting the timestamps of files, to reflect the timezone, even had to extract the archive on a *nix box and run “tar” to make sure it wasn’t a Windooze thing.
There is a 15 hour difference in timezones, between here and the web server, and in many cases, the file date was the next day, … hence the confusion. :confused:
So, timestamps of the extracted archive are definitely NOT a problem.
Please accept my apologies.
-
we added scroll bar to the archive folders bar, so it should work fine now. Please check with RC2 from our download page.
thanks!!!
-
Okay thanks, I’ll try it out.