This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Are you sure all compression modes are implemented? I don't think they are, afair 
that's also why I did not add them.

As the compression mechanisms are stored within the zip file itself, it isn't 
necessarily a requirement for php_zip to support compression/decompression of these 
types, just identification.

Using WinZip V15.0, I've created an archive with CM_PPMD, CM_LZMA, CM_BZIP and 
CM_WAVPACK compressions.

Still looking for LZ77 and Terse.

The compression types are correctly identified by php_zip, so having the constants 
makes sense to me.

I'll update the documentation to say that whilst identification of these types is 
performed, compression and decompression of these types is not currently supported.

If they are not implemented, no, it does not make sense to have them exposed. If 
one uses them he will then expect the compression mode to be set and used 
accordingly.

However for reading archive and get information about a given compression mode, 
yes. But only if they are actually used and set by libzip. If not, please revert 
this change.

I took a file (an uncompressed WAV file) and compressed it using WinZip V15 using different algorithms.

Using the following code ...

<?php
$zip = new ZipArchive;
$zip->open('wav.zipx');
foreach(range(0, $zip->numFiles - 1) as $index) {
	print_r($stat = $zip->statIndex($index));
	$zip->extractTo('.', array($stat['name']));
	echo $zip->getStatusString(), PHP_EOL;
}
$zip->close();


Outputs ...

Array
(
    [name] => WavPack.wav
    [index] => 0
    [crc] => 1384274557
    [size] => 154826
    [mtime] => 1296208410
    [comp_size] => 45366
    [comp_method] => 97
)
Compression method not supported
Array
(
    [name] => PPMD.wav
    [index] => 1
    [crc] => 1384274557
    [size] => 154826
    [mtime] => 1296208410
    [comp_size] => 100729
    [comp_method] => 98
)
Compression method not supported
Array
(
    [name] => LZMA.wav
    [index] => 2
    [crc] => 1384274557
    [size] => 154826
    [mtime] => 1296208410
    [comp_size] => 68162
    [comp_method] => 14
)
Compression method not supported
Array
(
    [name] => BZIP2.wav
    [index] => 3
    [crc] => 1384274557
    [size] => 154826
    [mtime] => 1296208410
    [comp_size] => 104633
    [comp_method] => 12
)
Compression method not supported


As you can see, 98, 97, 14 and 12 are all identified as the comp_method (correctly). None of these compression methods are supported by php_zip, but the constants should be present to allow determination of the method used.

Interestingly WavPack was the best algorithm to use on uncompressed audio (which WinZip performed when I asked it to "compress to the smallest size").

I can send the zip file if needed (300K).

I think it is important to remember that the zip files being accessed by php_zip may not have been produced by php_zip.

That's what I asked. We can keep them only and only if libzip detects AND uses 
these compression types correctly. It seems to be the case. Can you confirm it and 
maybe add a test per compression method?

Just as an aside, the error constants that ARE documented ... I can see no way to 
generate them. None of the methods or functions in php_zip return an error 
constant. Should these be removed?

Let try to keep this discussion sane...:

We can keep them only if it is supported at least to read the information about 
an entry. For example, if an entry uses LZ77, then doing a stat/reading the info 
MUST return CW_LZ77.

If that's not the case, then we must remove them as it makes no sense to expose 
them to the user.

Is it more clear now? :)

I've built a zip file containing the following compression methods (the table below shows the value, the constant name and ZipArchive::getStatusString()'s output when decompression is attempted and fails) :

0  : CM_STORE          : Decompression supported.
1  : CM_SHRINK         : Compression method not supported.
6  : CM_IMPLODE        : Compression method not supported.
8  : CM_DEFLATE        : Decompression supported.
9  : CM_DEFLATE64      : Compression method not supported.
10 : CM_PKWARE_IMPLODE : Compression method not supported.
12 : CM_BZIP2          : Compression method not supported.
14 : CM_LZMA           : Compression method not supported.
97 : CM_WAVPACK        : Compression method not supported.
98 : CM_PPMD           : Compression method not supported.

I cannot find any app that will create a ZIP file using the following compression methods.

2  : CM_REDUCE_1
3  : CM_REDUCE_2
4  : CM_REDUCE_3
5  : CM_REDUCE_4
18 : CM_TERSE
19 : CM_LZ77

I have Terse (Hercules app) and LZ77 (I think this is the Microsoft Compress format), but they do not create .ZIP files and the files magic-bytes are not zip related - so you can't just call the file a .zip file and get away with it.

I've got nowhere with REDUCE.

I've got a zip file and .phpt test to cover the compression methods I have found.

Given what I've found so far, I'm guessing that php_zip only really supports storing and deflating/inflating. The constants for the compression methods that I've managed to test should be exposed.

Those that I've not should be removed be unexposed and removed from the documentation.

But I'd like to add to the docs something along the lines of "Other compression methods may exist."

Richard.

> I've got a zip file and .phpt test to cover the compression
> methods I have found.

If you still have them, it would be great if you can make a PR.

> Given what I've found so far, I'm guessing that php_zip only
> really supports storing and deflating/inflating.

php_zip relies on libzip, and this supports only these two
methods, see
<http://www.nih.at/libzip/zip_set_file_compression.html>.

I'm sorry, I don't have this anymore. I can't recall what tools I used to generate the files all the compression methods. But from what I can recall is that one can create a zip file using a modern ZIP tool that php_zip / libzip would not be able to undo.

The table in http:///#1296487013 shows what I could create and what was supported at the time.

> But from what I can recall is that one can create a zip file
> using a modern ZIP tool that php_zip / libzip would not be able
> to undo.

Yes, that is definitely so. But that is not necessarily the issue
of this report, where it is about making the compression method
constants available, so they can be seen by doing a stat call. It
seems that your patch has already committed[1]. The only thing
that might be missing are some tests. I'll have a look at it.

[1] <http://lxr.php.net/xref/PHP_TRUNK/ext/zip/php_zip.c#3047>.

I remember that the issue was building a zip file that contained the different compression methods. As far as I was concerned, I just wanted to know the types if I read the archive.