ANN: Info-ZIP's Zip V2.32 is now available
Hunter Goatley
the web pages are still being updated, etc). I've added VMS binaries
for the different platforms and added the new release to my VMS
freeware archive.
I've included the Info-ZIP announcement below the URLs.
http://www.process.com/openvms/
ftp://ftp.process.com/vms-freeware/fileserv/zip.zip
http://vms.process.com/ftp/vms-freeware/fileserv/zip.zip
ftp://ftp.tmk.com/vms-freeware/fileserv/zip.zip
http://www.tmk.com/ftp/vms-freeware/fileserv/zip.zip
And on the other mirrors soon.
-----------------------------------------------------
Zip 2.32
We have posted Zip Release 2.32, June 19th 2006. This is a
patch release for the current Zip 2.3x and includes the following
changes. Also see the file WhatsNew and for details of all changes
see Changes.
New things in Zip 2.32
- Fixed -R operation to match the supplied file patterns in all recursed
subdirectories, like PKZIP 2.04 "-p -r" (or PKZIPC 4+ "-recurse")
- Handle cases where -x, -R, and -i patterns are mixed
- Fixes to ZipSplit, ZipNotes, and ZipCloak
- Example C-Sharp code added for using DLLs
- Implemented some directory search speedups
- Windows NTFS time fix
- Fix VMS logical name parse problem
- Handle VMS [...]
- Add VMS DEBUG option
- Fixed bug when encrypting large uncompressable files
- Updated VMS help
- Fix selecting files to delete by date
- Add -MM option where each input file pattern must match at least
one file and all input files must be readable
- Add check for when zip tries to exceed seek limit in output file
- Minor changes to compile with Visual C++ 2005
- Can now handle Unix FIFO (named pipes)
Note that Zip 3 (and UnZip 6) are currently in development and
these are planned to include large file and archive support
and many additional features.
-----------------------------------------------------
--
Hunter
------
Hunter Goatley, Process Software, http://www.process.com/
PreciseMail Anti-Spam Gateway for OpenVMS, Tru64, Solaris, & Linux
goath...@goatley.com http://www.goatley.com/hunter/
Dr. Dweeb
Since large file support is still a ways off (zip specification ??), is
there a VMS compression tool ala ZIP that is stable and usable for large
(30GB+) files ?
Dr. Dweeb
Craig A. Berry
"Dr. Dweeb" <sp...@dweeb.net> wrote:
> Since large file support is still a ways off (zip specification ??), is
> there a VMS compression tool ala ZIP that is stable and usable for large
> (30GB+) files ?
I have used bzip2 to zip large files (~12GB or so) on other platforms,
and I know assorted bzip2 versions are available on VMS. It should
work fine, but I can't say I've actually done the exact thing you need
to do. One advantage of bzip2 is that it gets better compression
ratios than anything else I've seen.
--
Posted via a free Usenet account from http://www.teranews.com
Hoff Hoffman
> In article <44a30fba$0$67258$157c...@dreader2.cybercity.dk>,
> "Dr. Dweeb" <sp...@dweeb.net> wrote:
>
>> Since large file support is still a ways off (zip specification ??), is
>> there a VMS compression tool ala ZIP that is stable and usable for large
>> (30GB+) files ?
I have a gzip port (1.3.3?) that has been in use for OpenVMS I64
DVDs, and we regularly use it for files beyond what zip can manage.
(IIRC, current versions of zip tend to tip over at or near 2GB.)
> I have used bzip2 to zip large files (~12GB or so) on other platforms,
> and I know assorted bzip2 versions are available on VMS. It should
> work fine, but I can't say I've actually done the exact thing you need
> to do. One advantage of bzip2 is that it gets better compression
> ratios than anything else I've seen.
I ported a version of bzip2 a while back, it wasn't a big deal. The
version I ported went out on the Freeware. V6 or V7?
unrar is also around, a port was just announced over at OpenVMS.Org.
Tom Linden
wrote:
> I have a gzip port (1.3.3?) that has been in use for OpenVMS I64 DVDs,
> and we regularly use it for files beyond what zip can manage. (IIRC,
> current versions of zip tend to tip over at or near 2GB.)
Do you have it for Alpha as well? If so, could you post it somewhere
please?
How is it an improvement on 1.2.4?
Hoff Hoffman
> Do you have it for Alpha as well? If so, could you post it somewhere
> please?
gzip 1.3.3 and likely 1.3.5-1 (if not later) will be generally
available on the Freeware V8.0 distribution. (Tom now has a copy of an
OpenVMS Alpha gzip port to look at; he probably didn't realize it, but
he just volunteered to test a gzip port for me. :-)
> How is it an improvement on 1.2.4?
Other than the large-file support that I centrally needed as part of
compressing the OpenVMS I64 DVD kits, I didn't particularly investigate
the details of the changes made to gzip after 1.2.4.
Tom Linden
wrote:
> Tom Linden wrote:
Testing it now, and will report back later. It would be nice if gzip
respected
version incrementation instead of overwriting.
HAFNER> dir $1$DGA2:[000000]common.sav*/size=unit=byte
Directory $1$DGA2:[000000]
COMMON.SAV;1 20.49GB
COMMON.SAV-GZ;1 5.03GB
FREJA> gzip COMMON.SAV
gzip: $1$DGA2:[000000]COMMON.SAV-gz already exists; do you wish to
overwrite (y
or n)? y
Tom Linden
> On Thu, 29 Jun 2006 11:28:41 -0700, Hoff Hoffman
> <hoff-rem...@hp.com> wrote:
>
>> Tom Linden wrote:
>>
>>> Do you have it for Alpha as well? If so, could you post it somewhere
>>> please?
>>
>> gzip 1.3.3 and likely 1.3.5-1 (if not later) will be generally
>> available on the Freeware V8.0 distribution. (Tom now has a copy of an
>> OpenVMS Alpha gzip port to look at; he probably didn't realize it, but
>> he just volunteered to test a gzip port for me. :-)
>>
>>> How is it an improvement on 1.2.4?
>>
>> Other than the large-file support that I centrally needed as part of
>> compressing the OpenVMS I64 DVD kits, I didn't particularly investigate
>> the details of the changes made to gzip after 1.2.4.
>>
>>
>>
> Testing it now, and will report back later. It would be nice if gzip
> respected
> version incrementation instead of overwriting.
>
> HAFNER> dir $1$DGA2:[000000]common.sav*/size=unit=byte
> Directory $1$DGA2:[000000]
> COMMON.SAV;1 20.49GB
> COMMON.SAV-GZ;1 5.03GB
>
BTW the zipped file above was not derived from that common.sav (that was
derived from an older copy) using the new gzip I get
COMMON.SAV-GZ;1 12.36GB
so a reduction from 20.49GB to 12.36GB or 40%
glenn everhart
The difference in compression is large here. I wonder: what is the
/group size that was used in the two originals? If the first had 0 so
there were no xor blocks, and the second had perhaps the default, I
would be totally UNsurprised by the observed difference. XOR blocks are
deadly for adaptive algorithms that just try to treat them as part of
the "normal" stream.
If the contents and the Backup factors like size of xor groups (and
record size: the backup record headers also compress less well than most
data and small blocksize will tend to compress worse than large) are the
same, then the difference in size of the result is really puzzling and
suggests something wrong.
Glenn Everhart
Tom Linden
wrote:
I used the default.
back dsa0:/image/verify
$1$DGA2:[000000]common.sav/save/ignore=(inter,noback)