BETA: PowerArchiver 2023 - 22.10.02

[TBGBe]

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

[peterr]

@TBGBe:

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.

[peterr]

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.

[spwolf]

@peterr:

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!

[peterr]

@spwolf:

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. :)

[peterr]

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. :(

[TBGBe]

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.

[peterr]

Thanks for doing that test. I also found if I used ZIP compression, the archive was okay.

[TBGBe]

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).

[peterr]

The 99 max seems to indicate a V7 version of TAR, from a few search results here

[spwolf]

With you guys doing all the work, there is nothing else for us to do…

;-)

[peterr]

@spwolf:

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 ?? ;)

[TBGBe]

@spwolf:

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:

[peterr]

@TBGBe:

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. :)

[peterr]

Any idea when this bug will be fixed please ??

[spwolf]

we are working on PAOP beta 2 right now, and then we will move to PA 2007 10.02

thanks!

[peterr]

@spwolf:

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

[amh209]

PAOP (Power Archiver Outlook Plug-in)

[spwolf]

we have no idea what will it include until we start working on it :-).

[TBGBe]

@TBGBe:

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