NanoZip .wcx plugin would be beneficial

[aLieN_Enemy]

Currently, NanoZip has the maximum possible compression ratio (considering the speed cost associated with it.).

FAR commander currently has a plugin for it. A .wcx plugin would be beneficial to everyone.

[Hacker]

[mod]Moved to the Plugins and Addons Forum.

Hacker (Moderator)[/mod]

[iana]

as that is a closed source format only the original author can make a wcx, on the other hand FAR dropped multiarc but TC still has a working multiarc plugin so it is quite possible lo write a multiarc script for nanozip
http://totalcmd.net/plugring/multiarc.html
writing a multiarc script is not difficult ... I've never done it but you can see the examples and try it out.
Personally I like new formats but for critical data you should use well known standardized archives like tar/zip/7zip/rar, nanozip is still alpha software.

edit
I searched for a FAR plugin but I couldn't find one (maybe it's an old FAR 2 multiarc script), can you please post a link to the FAR plugin.

[MVV]

Yes, Multiarc should be able to support nanozip.

BTW Multiarc was a bit updated, and 64-bit version added, but not on totalcmd.net. Links are in discussion topic.

It was funny to see unencoded filenames in archive, and in local charset instead of UTF-8... 7-zip supports Unicode, and it has beautiful structure, its directory is a table that is stored in a compressed stream just like all files!

[milo1012]

Currently, NanoZip has the maximum possible compression ratio (considering the speed cost associated with it.).

Who claims that?
I suggest you take a look at ZPAQ.
It's also a quite new archive format with highest compression, but seems way more mature to me.
I already did some basic implementation with multiarc,
but unfortunately the Journaling concept interferes.

It was funny to see unencoded filenames in archive, and in local charset instead of UTF-8

What is this statement about? NanoZip?
I wouldn't call this funny, but rather old-fashioned or premature, since the program is in alpha-stage (or an "experimental file archiver").
BTW, the good old zip format officially only supported Code Page 437, and there are still programs out there that don't support anything else.

7-zip supports Unicode, and it has beautiful structure, its directory is a table that is stored in a compressed stream just like all files!

There is no perfect directory structure, and you can't expect all archive formats to adopt the 7-zip concept.
Storing the dir in the stream itself can have some disadvantages when it comes to quick parsing of the archive.
And there is still no support for recovery data in 7-zip, although it has been discussed for years now.
I always have a hard time reconstructing damaged or partial 7-zip files.

[deus-ex]

Here's an addon for Multiarc to add support for Nanozip archives. Do not forget to adjust the path of the archiver and the Multiarc plugin accordingly:

Add to Multiarc.ini

Code: Select all

[NANOZIP]
Description="Nanozip"
Archiver=<path>\Nz.exe
Extension=nz
ID=AE 01 4E 61
UnixPath=1
Start="^yyyy-"
End="Total of "
Format0="yyyy TTT dd hh mm ss zz zzz zzz zzz +n++"
List=%P l -v %AAQ
BatchUnpack=1
ExtractWithPath=%P x -y %AAQ 

Add to wincmd.ini

Total Commander 32-bit

Code: Select all

[PackerPlugins]
nz=69,<path>\multiarc.wcx

Total Commander 64-bit

Code: Select all

[PackerPlugins]
nz=69,<path>\multiarc.wcx64

Note that there is an issue regarding display of the file sizes. Due to the way Nanozip provides its archive listings Total Commander only displays the right most 3 digits of the file size.

By default Nanozip displays the file size as a 4 digit value followed by a size indicator (B/KB/MB/GB). In verbose mode the file size is displayed as a decimal value, but using the space character for digit grouping instead of a usual dot, i.e. like so: "zz zzz zzz zzz". Thus Total Commander only accepts the last 3-digit group as the file size value, omitting any other parts of the reported fie size string.

Unfortunately I found no way to circumvent this problem with the available formatting options of MultiArc.


EDIT: removed an invalid entry from the Nanozip addon

[aLieN_Enemy]

Thank you for the code. I actually wrote one for myself 5 years ago, which might not be better than yours. Here it is:

Code: Select all

[NanoZIPs]
ID=DE 00 6E 61 6E 6F 7A 69 70
IDPos=0
Extension=nz
Archiver=c:\TotalCMD\Arc\NanoZIP\NANOZIP.exe 
Debug=0
Description=NanoZIP
Start="^Archive: "
End="^Total of "
         B.Misc.cache                         906 MB 2008-Dec-19 04:08:20 b40d8417
Format0="nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn zzzzzzz yyyy-TTT-dd hh:mm:ss"
List=%P l %a
Extract=%P x -y -d1 %a @%LQ
Test=%P t %a
Add=%P a -d1 -mz -cc %AQ @%LQ
Move=%P m -d1 -mz %AQ @%LQ

I will try to make a basic .wcx plugin for it in next month. However, if someone with more knowledge on C++ can do that, that would be great.

Here's an addon for Multiarc to add support for Nanozip archives. Do not forget to adjust the path of the archiver and the Multiarc plugin accordingly:

Add to Multiarc.ini

Code: Select all

[NANOZIP]
Description="Nanozip"
Archiver=<path>\Nz.exe
Extension=nz
ID=AE 01 4E 61
UnixPath=1
Start="^yyyy-"
End="Total of "
Format0="yyyy TTT dd hh mm ss zz zzz zzz zzz +n++"
List=%P l -v %AAQ
BatchUnpack=1
ExtractWithPath=%P x -y %AAQ 

Add to wincmd.ini

Total Commander 32-bit

Code: Select all

[PackerPlugins]
nz=69,<path>\multiarc.wcx

Total Commander 64-bit

Code: Select all

[PackerPlugins]
nz=69,<path>\multiarc.wcx64

Note that there is an issue regarding display of the file sizes. Due to the way Nanozip provides its archive listings Total Commander only displays the right most 3 digits of the file size.

By default Nanozip displays the file size as a 4 digit value followed by a size indicator (B/KB/MB/GB). In verbose mode the file size is displayed as a decimal value, but using the space character for digit grouping instead of a usual dot, i.e. like so: "zz zzz zzz zzz". Thus Total Commander only accepts the last 3-digit group as the file size value, omitting any other parts of the reported fie size string.

Unfortunately I found no way to circumvent this problem with the available formatting options of MultiArc.


EDIT: removed an invalid entry from the Nanozip addon

[LonerD]

deus-ex
It can't show files inside archive with lastest version (MultiArc MVV Build #8 32+64)
I created simply archive:
nz.exe a readme.txt.
Plugin open archive and show nothing inside.

aLieN_Enemy

ID=DE 00 6E 61 6E 6F 7A 69 70

Nanozip archive has ID=AE 01 4E 61

NANOZIP.exe

It's GUI, but console version nz.exe

[deus-ex]

deus-ex
It can't show files inside archive with lastest version (MultiArc MVV Build #8 32+64)
I created simply archive:
nz.exe a readme.txt.
Plugin open archive and show nothing inside.

ID=DE 00 6E 61 6E 6F 7A 69 70

LonerD,

you are referring to aLieN_Enemy's addon, the one I posted holds the correct archive ID and uses Nanozip's console version. Just scroll up a bit to my previous post above.

[LonerD]

you are referring to

I'm reffering that your addon don't work with lastest version of MultiArc (MVV Build #8).
I created simply archive:
nz.exe a readme.txt
Plugin can not display the contents of the archive.

[deus-ex]

The addon works fine here, with the latest release of MultiArc. Of course you made sure you adjusted the path in the addon, didn't you?

[MVV]

I found another stupid thing, and it is related to listing: if you disable adding some sort of information to archive (checksums, dates), archiver simply removes these columns from listing, so Multiarc format becomes completely wrong. Format string from deus-ex seems to be correct for files w/o checksums (flag -hn), but if someone creates archive with ones (with default settings) or w/o dates (flag -nt) this addon becomes invalid. Perhaps 18-byte signatures may help to distinguish different modes of listing but I'm not sure (bytes at offset 0x17 seem different but I don't know if it is a rule and not just coincidence), and what will be with next NanoZip version with another title string length?

E.g. this format string seems to be the most correct (except bad sizes) for default settings:

Code: Select all

Format0="         yyyy-TTT-dd hh:mm:ss zz zzz zzz zzz +n++"

This one is for archives w/o checksums:

Code: Select all

Format0="yyyy-TTT-dd hh:mm:ss zz zzz zzz zzz +n++"

This one is for archives w/o timestamps:

Code: Select all

Format0="          zz zzz zzz zzz +n++"

Last one is for archives w/o both checksums and timestamps:

Code: Select all

Format0=" zz zzz zzz zzz  n++"

And a starting string that works for any archive:

Code: Select all

Start="           size  file"

I think there won't be any luck with Multiarc until improving verbose output. E.g. Unrar uses multiline verbose output where it prints every parameter in a standard way so this allows parsing archives when some data isn't stored.

FAR commander currently has a plugin for it.

If it is really so (I can't find any information about this plugin and downloaded nigthly FAR build doesn't open nz files), proxy plugin may be created that will call this FAR plugin, and I think it will be the best way of using this just-another-archiver.

[deus-ex]

Hi MV,

that's quite an interesting find. So this is most probably why LonerD couldn't get my addon to work. Indeed my addon is tailored for creating Nanozip archives without checksums (-hn) and without storing file permissions (-np). Nanozip's archive listing in its current state is quite unfortunate, though I don't expect any improvements to the situation as the last release of Nanozip was issued back in November 2011.

Here is the command-line I'm using for Nanozip archiver in single-thread mode:

Code: Select all

nz.exe a -cc -hn -m5g -np -p1 -r <archive>

Note this command-line requires more than 5 GB (-m5g) of free RAM to execute. I experimented with Nanozip's memory switch and found that increasing the used RAM beyond 5 GB won't improve the compression any further in single-threaded mode. For multi-threaded compression the sweat spot appears to be at 13 GB.

[MVV]

Indeed my addon is tailored for creating Nanozip archives without checksums

Isn't it reckless to pack files w/o checksums using beta archiver?

Here is the command-line I'm using for Nanozip archiver in single-thread mode:

It is interesting how about memory consumption - is unpacking requires also 5 GB of RAM?
And, are there any really reasonable pros that NanoZip offers in compare to more popular archivers? In my little test it was significantly better than 7-Zip only with really time consuming mode. And unfortunately unpacking in such mode is also terribly slow, not only packing. And what if we compare NanoZip with FreeArc?

[deus-ex]

Isn't it reckless to pack files w/o checksums using beta archiver?

I don't use this compressor to archive any important data, it's just for testing purposes finding the best possible compression result. I was hoping for this archiver to evolve in time, but apparently the author of Nanozip has shifted his focus, probably due to real life constraints.

Are there any really reasonable pros that NanoZip offers in compare to more popular archivers? In my little tests it was significantly better than 7-Zip only with really time consuming mode. And unfortunately unpacking in such mode is also terribly slow, not only packing. Also, it is interesting how about memory consumption - is unpacking requires also 5 GB of RAM?

Indeed, in single-threaded mode Nanozip is quite time consuming. If you have a multi-core CPU try increasing the number of compressors used in parallel (-p#). E.g. for a quad-core CPU use -p4, for hexa-core use -p6. The speed-increase is quite incredible, depending on the data to compress it surpasses 7-Zip in terms of compression (better) and required time (less). But Nanozip's decompression speed is by far worse compared to 7-Zip's performance.