Zip file compression

There doesn’t seem to be any file compression utilities available for RISC OS that support more recent file compression formats and retains RISC OS file type information.

Luckily the libzip library (see libzip.org) supports more recent compression formats and makes it straight forward to retain RISC OS file types.

Enclosed in the zip file testzip.zip available from here are two simple ‘FrontEnd’ module apps. One called !testzip and the other !testunzip.

As the nane implies these are just simple test versions at the moment so may contain bugs and/or missing features.
For the fastest possible compression/decompression place everything in a RAM disc.

See the example screen shots below for how to use them.

Supported compression formats are,

store
deflate
bzip2
lzma
xz
zstd

Deflate and store are compatible with e.g. SparkFS. The other formats cause an ‘unsupported compression format’ if you try to extract the files using SparkFS. The contents of the zip files can still be navigated using SparkFS as they are just normal zip files but with an unsupported compression method.

Valid values for the compression level are 1-9. Use a lower number for faster compression.
Each compression format has it’s pros and cons. lzma and xz are much slower compressing but can produce much smaller zip files. zstd can give much faster compression/decompression speed for certain types of file.

One thing to look out for it that the directory and file paths are held as UTF8 in the zip file. Some file names will display incorrectly using e.g. SparkFS. !testunzip will convert them correctly when extracting from the zip file.

Also at the moment only folder paths can be compressed. So to compress a single file it must be located in a folder.

What’s the purpose of the TimerMod RMEnsure in the !Run files of both?

Thanks for that. Do you have a front-end to test an (some) existing zip(s)?

Do you have a front-end to test

… on an emulation platform? Like RPCEmu.

There is testzip and testunzip. I ask if there could be also a testcheckzip application.

Could a ZLib wrapper be put on libzip so it can be rolled into the OS and replace the current version?

One of the things on my list of things to code is a filing system for ZIP which will go into the OS. Primarily this was for RISCOS 3.20 so I can reduce the size of Resources, but I don’t see why it couldn’t go into the main source tree and replace SparkFS.

libzip sounds like it might have benefits over the current ZLib implementation.

Thanks for this, a bit of real world compatibility.

Just one minor snaglet with testunzip.

Using !testunzip to unzip its own download, the entries in the dialogue box are by drags and are :-

Zip     ADFS::Titan4.$.Work.Proj.TestZip.testzip/zip

Folder  ADFS::Titan4.$.Work.Proj.TestZip.Zonk

The unzips appear in two folders :-

ADFS::Titan4.$.Work.Proj.TestZip.Zonk!testunzip
ADFS::Titan4.$.Work.Proj.TestZip.Zonk!testzip

Adding a trailing dot to the destination folder works.

There is testzip and testunzip. I ask if there could be also a testcheckzip application.

They are just normal zip files so testing with SparkFS or ‘unzip -t’ will work for the ‘deflate’ or ‘store’ zip file. I can create a ‘testcheckzip’ application to test them and/or list the contents with compression rates.

Just one minor snaglet with testunzip.

Thanks. I’ll fix that in the next version which should also include being able to decrypt/encrypt zip files.

Thanks!

There’s an updated version of testzip and testunzip available here.

Now includes testzipcheck for testing a zip file. It’s also now possible to create, extract or test a zip file which has been encrypted with a password.

Could a ZLib wrapper be put on libzip so it can be rolled into the OS and replace the current version?

In theory it should be possible. Libzip already uses ZLib. It’s written in C so should be compilable with the Norcroft C compiler. Libzip also uses libbz2, liblzma and libztd which I believe are also written in C.

Thank you for releasing these tools. A quick test, !testzipcheck works out of the box. !testzip and !testunzip require system:modules.TimerMod (RPi4, RO 5.29 22-dec-20)

A quick test, !testzipcheck works out of the box. !testzip and !testunzip require system:modules.TimerMod (RPi4, RO 5.29 22-dec-20)

I was waiting (5 days) for someone else to comment on why a compression/decompression tool needs TimerMod. Or has no one registered that that requirement excludes a block of users without any explanation?