Actually, I discovered the problem: the plugin writes the backup file incrementally, appending a batch of data every couple of seconds. The problem is that gzclose writes the uncompressed file size as being that of only the latest batch.

I'll have to figure out a solution.

OK, thanks. I'e used other php apps such phpmydamin and the gzip files do seem to be follow the spec, but I have no idea whether phpmyadmin or the other apps I've had no problems with also use the standard php gzip routines.

That's interesting, but I'm not sure there's anything I can do about it. The plugin uses the PHP gzip writing functions, so if they're not writing the file according to spec I suspect the problem needs to be fixed upstream.

Hello:

When trying to open a compressed gzipped database backup in BBEdit, my text editing software of choice, BBEdit crashed. I raised the issue with the folks at Bare Bones who develop BBEdit, giving them the file which was at issue, and they said they found the problem and gave me a technical description of the problem. I'm hopeful you might be able to figure out if the problem is in your plug-in or in Wordpress generally:

The technical description is that the last four bytes of a gzip-compressed file are the size of the uncompressed data, written in least-significant-byte-first order. In the file you sent, the last four bytes are 0x6A 0x00 0x00 0x00, which corresponds to a data size of 0x6A (106) bytes. I was allocating buffers based on that information, and you can imagine what happened next. :-)

Any thoughts? Thanks. I'm running the latest version of WP-DB on Wordpress 2.8, though I had the same malformed file error with backups made using earlier versions of WP. Of note, the gzipped file does expand correctly using Mac OS X's built-in unarchiver.