Filename extensions changed ??
-
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.






