#48763 [Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
Assigned To: pajoye
New Comment:
RalfBecker: In fact, one probable workaround, until this bug gets
fixed, is to iterate through EVERY file in the ZipArchive, get the
contents, and addFromString to put them back into the archive. By
overwriting every single file in the archive (with its own contents),
you won't trigger the bug.
Previous Comments:
[2009-07-04 08:29:41] RalfBecker at outdoor-training dot de
I can reproduce that bug with php5.2.9 under openSUSE11.0, thought I
tried so far only oo3 *.odt files. It seems not to depend on the file,
in fact I can not create a file, where I can replace content.xml with
itself, without corrupting it.
Ralf
[2009-07-04 00:53:02] dani dot church at gmail dot com
The patch, a PHP testbed, and a test ZIP file (empty.zip) can all be
found at http://dchurch.ath.cx/phpzip/. The test ZIP is minimal and
contains one empty file that uses a data descriptor. The PHP testbed
takes this ZIP file, sets the modified flag by adding and removing a
dummy file, and writes the results back to the browser. The ZIP file
that PHP writes back to the browser is identical to the input file with
the following exceptions:
1) The data descriptor, addresses 0x23-0x32 in the original file, is
missing. The central directory starts at 0x33 in the original file, and
at 0x23 in the modified file.
2) The central directory address, stored at 0x76 in the original file
and 0x66 in the modified file, is updated from 0x33 to 0x23.
3) The local file header contains the flag 0x08 at address 0x06 to
indicate that a data descriptor is present. This flag is cleared.
4) The central directory file header contains the flag 0x08 at address
0x3b (corresponding to 0x2b in the modified file), which is a copy of
the same flag at 0x06. This flag SHOULD be cleared, but in the current
CVS, it does not get cleared. The patch clears this flag.
I don't have a test case for the other bug I found, since the if block
at lines 173-185 seems to be something that isn't supposed to happen in
the normal flow of execution. At the very least, I can't figure out a
way to get to that point with ch_filename == NULL. However, if that
block ever did get executed, it would result in a central directory
entry with a listed filename length of 0 but the character - in the
filename field-- again, an invalid ZIP file.
[2009-07-03 17:35:24] paj...@php.net
Ah thanks guys :)
Do you have test cases for these two bugs (this one and the other you
found while writing the patch)? It will help to valid the patch before I
apply it. If you can post a link to the patch and the tests.
Thanks for your work!
[2009-07-03 02:33:42] dani dot church at gmail dot com
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
- memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
}
if (za-entry[i].ch_filename
#48763 [Fbk-Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
Assigned To: pajoye
New Comment:
The patch, a PHP testbed, and a test ZIP file (empty.zip) can all be
found at http://dchurch.ath.cx/phpzip/. The test ZIP is minimal and
contains one empty file that uses a data descriptor. The PHP testbed
takes this ZIP file, sets the modified flag by adding and removing a
dummy file, and writes the results back to the browser. The ZIP file
that PHP writes back to the browser is identical to the input file with
the following exceptions:
1) The data descriptor, addresses 0x23-0x32 in the original file, is
missing. The central directory starts at 0x33 in the original file, and
at 0x23 in the modified file.
2) The central directory address, stored at 0x76 in the original file
and 0x66 in the modified file, is updated from 0x33 to 0x23.
3) The local file header contains the flag 0x08 at address 0x06 to
indicate that a data descriptor is present. This flag is cleared.
4) The central directory file header contains the flag 0x08 at address
0x3b (corresponding to 0x2b in the modified file), which is a copy of
the same flag at 0x06. This flag SHOULD be cleared, but in the current
CVS, it does not get cleared. The patch clears this flag.
I don't have a test case for the other bug I found, since the if block
at lines 173-185 seems to be something that isn't supposed to happen in
the normal flow of execution. At the very least, I can't figure out a
way to get to that point with ch_filename == NULL. However, if that
block ever did get executed, it would result in a central directory
entry with a listed filename length of 0 but the character - in the
filename field-- again, an invalid ZIP file.
Previous Comments:
[2009-07-03 17:35:24] paj...@php.net
Ah thanks guys :)
Do you have test cases for these two bugs (this one and the other you
found while writing the patch)? It will help to valid the patch before I
apply it. If you can post a link to the patch and the tests.
Thanks for your work!
[2009-07-03 02:33:42] dani dot church at gmail dot com
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
- memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
}
if (za-entry[i].ch_filename) {
[2009-07-02 22:52:00] ras...@php.net
I don't know this code at all, but just poking around in CVS I would
say the most likely change that is able to cause those differences is
this one:
http://cvs.php.net/viewvc.cgi/php-src/ext/zip/lib/zip_close.c?r1=1.1.2.9r2=1.1.2.12sortby=date
[2009-07-02 22:35:22] dani dot church at gmail dot com
Here's a binary diff of the two zip files. Summary: 5 places where an
0x08 byte changed to 0x00, and two places where an 0x06 byte changed to
0x44. Given the values of comp_method in the stat calls, my wild guess
is that comp_method somehow does not get stored properly in 5.2.8+. I
don't know the code
#48763 [Fbk-Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
New Comment:
Here's a binary diff of the two zip files. Summary: 5 places where an
0x08 byte changed to 0x00, and two places where an 0x06 byte changed to
0x44. Given the values of comp_method in the stat calls, my wild guess
is that comp_method somehow does not get stored properly in 5.2.8+. I
don't know the code, though.
If necessary, I can host the original files on my server for download.
--- empty-5.2.6.xxd 2009-07-02 18:27:28.0 -0400
+++ empty-5.2CVS2009-07-01.xxd 2009-07-02 18:27:28.0 -0400
@@ -7,7 +7,7 @@
060: e23a 1a00 .:..
070: 436f 6e66 6967 7572 6174 696f 6e73 ..Configurations
080: 322f 7374 6174 7573 6261 722f 504b 0304 2/statusbar/PK..
-090: 1400 0808 0800 00b3 e23a 0200 .:..
+090: 1400 0008 0800 00b3 e23a 0200 .:..
0a0: 2700 436f 6e66 6967 ..'...Config
0b0: 7572 6174 696f 6e73 322f 6163 6365 6c65 urations2/accele
0c0: 7261 746f 722f 6375 7272 656e 742e 786d rator/current.xm
@@ -32,7 +32,7 @@
1f0: b3e2 3a00 :...
200: 001f 0043 6f6e 6669 6775 7261 7469 .Configurati
210: 6f6e 7332 2f69 6d61 6765 732f 4269 746d ons2/images/Bitm
-220: 6170 732f 504b 0304 1400 0808 0800 00b3 aps/PK..
+220: 6170 732f 504b 0304 1400 0008 0800 00b3 aps/PK..
230: e23a 8d6c f030 aa05 3619 0a00 .:.l.06.
240: 7374 796c 6573 2e78 6d6c dd59 6d6f ..styles.xml.Ymo
250: db36 10fe be5f 2128 43b1 0293 253b 6913 .6..._!(C...%;i.
@@ -171,7 +171,7 @@
aa0: 6765 6e65 7261 746f 723e 3c2f 6f66 6669 generator/offi
ab0: 6365 3a6d 6574 613e 3c2f 6f66 6669 6365 ce:meta/office
ac0: 3a64 6f63 756d 656e 742d 6d65 7461 3e50 :document-metaP
-ad0: 4b03 0414 0008 0808 b3e2 3a70 6c4c K...:plL
+ad0: 4b03 0414 0808 b3e2 3a70 6c4c K...:plL
ae0: 647b 00f8 0200 0018 0054 6875 d{...Thu
af0: 6d62 6e61 696c 732f 7468 756d 626e 6169 mbnails/thumbnai
b00: 6c2e 706e 67eb 0cf0 73e7 e592 e262 6060 l.png...sb``
@@ -182,7 +182,7 @@
b50: c112 c939 26cd 93d3 0a2e f1f8 cd3a e869 ...9:.i
b60: 6c91 392a 382a 38e0 82b7 582f 7e64 fb77 l.9*8*8...X/~d.w
b70: 4d82 b51b 94a2 3d5d fd5c d639 2534 0100 M.=].\.9%4..
-b80: 504b 0304 1400 0808 0800 00b3 e23a 2124 PK...:!$
+b80: 504b 0304 1400 0008 0800 00b3 e23a 2124 PK...:!$
b90: 3734 8e03 e01b 0c00 7365 74se
ba0: 7474 696e 6773 2e78 6d6c ed99 5153 e230 ttings.xml..QS.0
bb0: 10c7 dfef 5330 7dc7 0272 dcd9 111c c4f1 S0}..r..
@@ -241,7 +241,7 @@
f00: 5f4d 10f6 19d3 c536 8aa2 9f38 1910 ee00 _M.6...8
f10: aba0 e022 7147 ba1a 2267 cb0a fc34 9467 ...qG..g...4.g
f20: ab0f 51b6 0eb2 e24c f086 89c2 d3a5 f9ea ..QL
-f30: 2394 59f4 79ae f71f 504b 0304 1400 0808 #.Y.y...PK..
+f30: 2394 59f4 79ae f71f 504b 0304 1400 0008 #.Y.y...PK..
f40: 0800 00b3 e23a 4154 fb43 4901 6807 .:AT.CI...h.
f50: 1500 4d45 5441 2d49 4e46 2f6d ..META-INF/m
f60: 616e 6966 6573 742e 786d 6cb5 9541 6ec3 anifest.xml..An.
@@ -265,7 +265,7 @@
0001080: 7bf5 2e3c f9f9 7fcd fc3b 97f8 6490 66c7 {...;..d.f.
0001090: 0ec8 30db c1b3 ddc7 6167 411b 927c 1956 ..0.agA..|.V
00010a0: def6 73c3 e72d 2c32 a7eb f25a da95 fc71 ..s..-,2...Z...q
-00010b0: 5bae 3f01 504b 0304 1400 0800 0693 [.?.PK..
+00010b0: 5bae 3f01 504b 0304 1400 0800 4493 [.?.PKD.
00010c0: e23a 75e5 4403 7003 6f0e 0b00 .:u.D.p...o.
00010d0: 636f 6e74 656e 742e 786d 6ce5 574d ..content.xml.WM
00010e0: 8fdb 3610 bde7 5718 2ad0 1bcd b5b7 4176 ..6...W.*.Av
@@ -382,7 +382,7 @@
00017d0: 54fb 4349 0100 0068 0700 0015 T.CI...h
00017e0: 0038 0f00 004d 4554 .8...MET
00017f0: 412d 494e 462f 6d61 6e69 6665 7374 2e78 A-INF/manifest.x
-0001800: 6d6c 504b 0102 1400 0800 0693 mlPK
+0001800: 6d6c 504b 0102 1400 0800 4493 mlPK..D.
0001810: e23a 75e5 4403 7003 6f0e 0b00 .:u.D.p...o.
0001820: b410
0001830: 636f 6e74 656e 742e 786d 6c50 4b05 0600 content.xmlPK...
Previous Comments:
[2009-07-02 22:02:15] j...@php.net
Can you try finding out what the difference is between the packages
produced by 5.2.6 and latest release
#48763 [Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
New Comment:
You're absolutely right, that's the file with the bug. Both PHP 5.2.6
and 5.2.8+ produce malformed ZIP files, in slightly different ways,
though only when UPDATING (not creating from scratch) ZIP files. The
zip library does not write optional data descriptors, even if the input
file has them. In 5.2.6, the data descriptor exists flag is set, even
though there is no data descriptor. In 5.2.8+, the flag is (properly)
cleared in the local file header, but not in the central directory.
OpenOffice.org tolerates the bug in 5.2.6 but not the one in 5.2.8+. A
patch to fix this bug (and another minor bug I found in the same area)
follows:
--- ext/zip/lib/zip_close.c.orig2009-07-02 21:40:03.0
-0400
+++ ext/zip/lib/zip_close.c 2009-07-02 22:24:54.0 -0400
@@ -175,6 +175,7 @@
de.filename = strdup(-);
de.filename_len = 1;
cd-entry[j].filename = -;
+ cd-entry[j].filename_len = 1;
}
else {
de.filename = strdup(za-cdir-entry[i].filename);
@@ -195,13 +196,14 @@
error = 1;
break;
}
+ memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
if (de.bitflags ZIP_GPBF_DATA_DESCRIPTOR) {
de.crc = za-cdir-entry[i].crc;
de.comp_size = za-cdir-entry[i].comp_size;
de.uncomp_size = za-cdir-entry[i].uncomp_size;
de.bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
+ cd-entry[j].bitflags = ~ZIP_GPBF_DATA_DESCRIPTOR;
}
- memcpy(cd-entry+j, za-cdir-entry+i,
sizeof(cd-entry[j]));
}
if (za-entry[i].ch_filename) {
Previous Comments:
[2009-07-02 22:52:00] ras...@php.net
I don't know this code at all, but just poking around in CVS I would
say the most likely change that is able to cause those differences is
this one:
http://cvs.php.net/viewvc.cgi/php-src/ext/zip/lib/zip_close.c?r1=1.1.2.9r2=1.1.2.12sortby=date
[2009-07-02 22:35:22] dani dot church at gmail dot com
Here's a binary diff of the two zip files. Summary: 5 places where an
0x08 byte changed to 0x00, and two places where an 0x06 byte changed to
0x44. Given the values of comp_method in the stat calls, my wild guess
is that comp_method somehow does not get stored properly in 5.2.8+. I
don't know the code, though.
If necessary, I can host the original files on my server for download.
--- empty-5.2.6.xxd 2009-07-02 18:27:28.0 -0400
+++ empty-5.2CVS2009-07-01.xxd 2009-07-02 18:27:28.0 -0400
@@ -7,7 +7,7 @@
060: e23a 1a00 .:..
070: 436f 6e66 6967 7572 6174 696f 6e73 ..Configurations
080: 322f 7374 6174 7573 6261 722f 504b 0304 2/statusbar/PK..
-090: 1400 0808 0800 00b3 e23a 0200 .:..
+090: 1400 0008 0800 00b3 e23a 0200 .:..
0a0: 2700 436f 6e66 6967 ..'...Config
0b0: 7572 6174 696f 6e73 322f 6163 6365 6c65 urations2/accele
0c0: 7261 746f 722f 6375 7272 656e 742e 786d rator/current.xm
@@ -32,7 +32,7 @@
1f0: b3e2 3a00 :...
200: 001f 0043 6f6e 6669 6775 7261 7469 .Configurati
210: 6f6e 7332 2f69 6d61 6765 732f 4269 746d ons2/images/Bitm
-220: 6170 732f 504b 0304 1400 0808 0800 00b3 aps/PK..
+220: 6170 732f 504b 0304 1400 0008 0800 00b3 aps/PK..
230: e23a 8d6c f030 aa05 3619 0a00 .:.l.06.
240: 7374 796c 6573 2e78 6d6c dd59 6d6f ..styles.xml.Ymo
250: db36 10fe be5f 2128 43b1 0293 253b 6913 .6..._!(C...%;i.
@@ -171,7 +171,7 @@
aa0: 6765 6e65 7261 746f 723e 3c2f 6f66 6669 generator/offi
ab0: 6365 3a6d 6574 613e 3c2f 6f66 6669 6365 ce:meta/office
ac0: 3a64 6f63 756d 656e 742d 6d65 7461 3e50 :document-metaP
-ad0: 4b03 0414 0008 0808 b3e2 3a70 6c4c K...:plL
+ad0: 4b03 0414 0808 b3e2 3a70 6c4c K...:plL
ae0: 647b 00f8 0200 0018 0054 6875 d{...Thu
af0: 6d62 6e61 696c 732f 7468 756d 626e 6169 mbnails/thumbnai
b00: 6c2e 706e 67eb 0cf0 73e7 e592 e262 6060 l.png...sb``
@@ -182,7 +182,7 @@
b50: c112 c939 26cd 93d3 0a2e f1f8 cd3a e869 ...9:.i
b60: 6c91 392a 382a 38e0 82b7 582f 7e64 fb77 l.9*8*8...X/~d.w
b70: 4d82 b51b 94a2 3d5d fd5c d639 2534 0100 M.=].\.9%4..
-b80: 504b 0304 1400 0808 0800 00b3 e23a 2124
#48763 [NEW]: ZipArchive produces corrupt OpenOffice.org files
From: dani dot church at gmail dot com
Operating system: CentOS 5
PHP version: 5.2CVS-2009-07-01 (snap)
PHP Bug Type: Zip Related
Bug description: ZipArchive produces corrupt OpenOffice.org files
Description:
When PHP writes a .od* file using ZipArchive, the resulting archive cannot
be opened by OpenOffice.org. The error it gives is The file 'filename' is
corrupt and therefore cannot be opened. Should OpenOffice.org repair the
file?
Repairing the file in OO.o does not work. However, unzipping the file
from the command line (using unzip in OSX) works without error, and unzip
-t (test integrity) reports no errors. Furthermore, the extracted files
are byte-correct, and zipping the extracted files into a new .od* file
results in a valid OpenOffice.org file.
This bug is a regression since 5.2.6. Using zip.so from 5.2.6 results in
a valid file. Using zip.so from 5.2CVS-2009-07-01 results in a corrupt
file.
Reproduce code:
---
?php
if (isset($_FILES['od'])) {
$odfile = $_FILES['od']['tmp_name'];
$zip = new ZipArchive();
$zip-open($odfile);
$xml = $zip-getFromName('content.xml');
$zip-addFromString('content.xml', $xml);
$zip-close();
header('content-type: application/vnd.oasis.opendocument.spreadsheet');
header('content-disposition: attachment;filename=test.ods');
readfile($odfile);
unlink($odfile);
return;
}
?
form method=POST enctype=multipart/form-data
input type='file' name='od'
input type='submit'
/form
Expected result:
Using the above testbed (for ODS spreadsheets) to update content.xml with
its own data should result in a valid ODS spreadsheet.
Actual result:
--
The resulting spreadsheet is corrupt and cannot be opened.
--
Edit bug report at http://bugs.php.net/?id=48763edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48763r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48763r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48763r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48763r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48763r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48763r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48763r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48763r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48763r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48763r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48763r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48763r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48763r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48763r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48763r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48763r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48763r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48763r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48763r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48763r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48763r=mysqlcfg
#48763 [Opn]: ZipArchive produces corrupt OpenOffice.org files
ID: 48763
User updated by: dani dot church at gmail dot com
Reported By: dani dot church at gmail dot com
Status: Open
Bug Type: Zip Related
Operating System: CentOS 5
PHP Version: 5.2CVS-2009-07-01 (snap)
New Comment:
I sampled the compressed file using statName() three times: once before
updating it, once after the addFromString() call, and once after closing
the ZIP and reopening it from another object. The results:
Original file: Array
(
[name] = content.xml
[index] = 11
[crc] = 2790848447
[size] = 16096
[mtime] = 1246486396
[comp_size] = 2379
[comp_method] = 8
)
Compressed, not saved: Array
(
[name] = content.xml
[index] = 20
[crc] = 0
[size] = 16096
[mtime] = 1246493476
[comp_size] = -1
[comp_method] = 0
)
Compressed and reopened: Array
(
[name] = content.xml
[index] = 19
[crc] = 2790848447
[size] = 16096
[mtime] = 1246493476
[comp_size] = 2355
[comp_method] = 8
)
Notably, the compression method is the same, which means that PHP is
not trying to use a compression method that OpenOffice.org does not
support.
Previous Comments:
[2009-07-01 23:48:05] dani dot church at gmail dot com
Description:
When PHP writes a .od* file using ZipArchive, the resulting archive
cannot be opened by OpenOffice.org. The error it gives is The file
'filename' is corrupt and therefore cannot be opened. Should
OpenOffice.org repair the file?
Repairing the file in OO.o does not work. However, unzipping the file
from the command line (using unzip in OSX) works without error, and
unzip -t (test integrity) reports no errors. Furthermore, the extracted
files are byte-correct, and zipping the extracted files into a new .od*
file results in a valid OpenOffice.org file.
This bug is a regression since 5.2.6. Using zip.so from 5.2.6 results
in a valid file. Using zip.so from 5.2CVS-2009-07-01 results in a
corrupt file.
Reproduce code:
---
?php
if (isset($_FILES['od'])) {
$odfile = $_FILES['od']['tmp_name'];
$zip = new ZipArchive();
$zip-open($odfile);
$xml = $zip-getFromName('content.xml');
$zip-addFromString('content.xml', $xml);
$zip-close();
header('content-type:
application/vnd.oasis.opendocument.spreadsheet');
header('content-disposition: attachment;filename=test.ods');
readfile($odfile);
unlink($odfile);
return;
}
?
form method=POST enctype=multipart/form-data
input type='file' name='od'
input type='submit'
/form
Expected result:
Using the above testbed (for ODS spreadsheets) to update content.xml
with its own data should result in a valid ODS spreadsheet.
Actual result:
--
The resulting spreadsheet is corrupt and cannot be opened.
--
Edit this bug report at http://bugs.php.net/?id=48763edit=1
