" invalid " archives from other programs

[ineloquucius]

When I create large .zip's with PACL, I am unable to open them with either the buit in windows zip extractor, or 7-zip, or Power Archiver full. Yet "paext -t" doesn't have a any issue them. I have not yet had an opportunity to try an actual extraction, but I'll assume for the moment that if the "-t" test succeeded, and the file size looks roughly correct that I can still extract files just fine with PACL.

Any reason why 1Gb+ files compressed in PACL wouldn't be extractable or viewable from other zippers?

Thanks.

[spwolf]

What is exact size? PACL does not support zip 4.5 standard (large zip archives).

thanks,

[ineloquucius]

is one example. Where does pacl cut off?

(thanks for the reply, btw).

[spwolf]

is 1.4 GB resulting zip archive or? And what is original file size of the files being compressed?

There is an 2 GB limit to the max file size of zip archive in PACL, however I also believe there is an 4 GB limit to the total file sizes of the files being compressed.

thanks,

[ineloquucius]

28Gb>1.5Gb. Incidentally, where does one find this kind of information? So far, I can't find anything outside of the manual.txt.

Thanks again.

[spwolf]

manual.txt has limitations info.

What exactly do you need to do? Since PA 2006 has backup wizard that creates scripts you can run to backup files and no file size limitations.

thanks,

[TBGBe]

Originally Posted by ineloquucius

... Incidentally, where does one find this kind of information? So far, I can't find anything outside of the manual.txt.

Neither could I - hence WishList :-
http://www.powerarchiver.com/forums/...read.php?t=994

[ineloquucius]

Should I not, then, trust the success of the "paext -t" results when they return optimistically?

I like using the command line because it makes it easy for me to implement .cmd scripts that use a naming convention of my choice for the archive and log files. It also enables automated copying of these files to appropriate media and directories, based on content, date, and type of backup.

Also, I'm not sure how I'd use cron to launch PA, though that's likely just a matter of familiarity with the application.

I'll have to rethink my strategies.

Thanks for your answers.

[TBGBe]

Originally Posted by ineloquucius

Should I not, then, trust the success of the "paext -t" results when they return optimistically?

No. Only valid for <2GB

Originally Posted by ineloquucius

I like using the command line because it makes it easy for me to implement .cmd scripts that use a naming convention of my choice for the archive and log files. It also enables automated copying of these files to appropriate media and directories, based on content, date, and type of backup.

Also, I'm not sure how I'd use cron to launch PA, though that's likely just a matter of familiarity with the application.

Don't launch PA. Create a "backup script" (*.pbs) and launch that. You already have a wide range of options within the script.

[ineloquucius]

Is it the .zip format itself, and not PACL that has these size limitations? If I were to use a different format, perhaps the file size is not an issue?

Unfortunately, since the archive viewing and testing is reporting success with the oversized zip files, and working in a production environment, I can't simply try-it-out so easily. Just wondering if anyone knew whether it was a format limitation, rather than a PACL one.

[spwolf]

it is zip 2.04 format limitation, which is zip format that PACL supports fully.

Zip 4.5 does not have that limitation, but is not fully supported by PACL.

[TBGBe]

Originally Posted by ineloquucius

...28Gb.
... If I were to use a different format, perhaps the file size is not an issue?...

I believe that all the compression formats, as currently supported by PACL, would fail with that large a data set.