I have php 4.0.4pl1 under Apache. My zlib is version 1.1.2.

I've had problems accessing gz compressed file : 
This happens in the middle of a file : 'gzeof' don't catch
any EOF, but 'gzgetc' returns false as it was the end of the
file. Same for 'gzread' which acts exactly as if it had
encountered an EOF.
I open the compressed file for writing, and write with the
lines (and only these one): 

$zp = gzopen($this->file, "ab9");
gzwrite($zp,  strlen($string) . chr(0)
	    . $string         . chr(0)
	    . "0"             . chr(0)
           , strlen($string) + strlen(strlen($string)) + 4);

I open the compressed file for reading, and read with the
lines (and only these ones): 

$zp = gzopen($this->file, "rb");
$char = gzgetc($zp);
$string = gzread($zp, $SizeOfString);

This simple script can't read all the file : 

// Note : The file is 68 bytes long uncompressed, and 128
compressed (this info has been read with ls -al)

 $fd = gzopen($file,"rb");
 echo bin2hex(gzread ($fd, 1000));
 gzclose($fd);



This happens on ext2 file system, and vfat. But doesn't
happen under a foreign server (which I don't know the exact
configuration, but has only php 3.16 probably running under
apache on a linux 2.2.14 (for more info on this server go :
http://neosyris.free.fr/testphp.php3)). Their zlib is
version 1.1.3.

I've gunzipped the file I couldn't read in PHP, and read it
without any problems with gz* function by taking of the "9"
in the gzopen function. Although it seems it make the same
problems with other compression values.

I've opened the gunzziped file, and this one contains only
normal caracters except the '00' char. (checked this with
'hexdump showbug -c').

my configure line : 

--prefix=/usr/apps/apache --with-zlib --with-mysql
--with-apxs=/usr/apps/apache/bin/apxs
--with-config-file-paht=/usr/apps/apache/conf

I hope this could help. Last thing : I placed a file that
causes problems on http://neosyris.free.fr/showbug.gz

All these bugs could come from zlib version 1.1.2, downloading version 1.1.3 could resolve the issues. Finding
zlib source isn't always easy, so there is some addresses :
www.freshmeat.net
ftpsearch.ntnu.org

****** An add from Craig about zlib 1.1.3 on WinME *******

I can confirm this bug. I have php4.04pl1 on two seperate linux installs as well as a windows ME installation.
(All are with Apache 1.3.14).
 
Using the same scripts and data the gzread and gzfile WILL WORK correctly on the linux installs but NOT on the windows install.
ie. Only a portion of the gzfile is read into the script.
a phpinfo() on all three installs reports a zlib version 1.1.3
 
It may be that the 1.1.3 zlib was fixed for the linux install, but not the windows ??????

**********

Hmm, it really could be a bug in zlib 1.1.2, they fixed some gz...-related bugs with 1.1.3. If possible, try to install 1.1.3 on your box and if it works, please close this bug report.

Do you use repeating gzopen($this->file, "ab9") calls to write to this file? Maybe it helps if you change it, so that you write the file at once und use only one gzopen($this->file, "wb9") call. Appending to gz-files is like concatenating .gz-files which doesn't work very well (and the compression is even worse if you append only small pieces).

I've tested with zlib-1.1.3 and all my problems vanished. 
Thanks for the support, though it wasn't a php bug. I'll
close this bug report.

PHP.net provides a really handy structure for developpers.

"Chapeau bas !"