Message123954
| Author |
KevinH |
| Recipients |
KevinH, xuanji |
| Date |
2010年12月14日.15:34:20 |
| SpamBayes Score |
5.663129e-07 |
| Marked as misclassified |
No |
| Message-id |
<1292340864.52.0.98971095846.issue10694@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Here is one potential patch. It simply incorporates and non-comment extraneous data into a final comment so that nothing is lost. Another solution that might be safer, would be to truncate the zip archive immediately after the endrec is found if the extraneous data is not a properly formatted comment. The right solution is obviously up to the developers of zipfile.py
--- zipfile_orig.py 2010年12月14日 10:23:58.000000000 -0500
+++ zipfile.py 2010年12月14日 10:30:21.000000000 -0500
@@ -228,6 +228,13 @@
# structure present, so go look for it
return _EndRecData64(fpin, start - filesize, endrec)
return endrec
+ else :
+ # be robust to non-comment extaneous data after endrec
+ # by making it a comment so that nothing is ever lost
+ endrec[_ECD_COMMENT_SIZE] = len(comment)
+ endrec.append(comment)
+ endrec.append(maxCommentStart + start)
+ return endrec
# Unable to find a valid end of central directory structure
return |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年12月14日 15:34:24 | KevinH | set | recipients:
+ KevinH, xuanji |
| 2010年12月14日 15:34:24 | KevinH | set | messageid: <1292340864.52.0.98971095846.issue10694@psf.upfronthosting.co.za> |
| 2010年12月14日 15:34:20 | KevinH | link | issue10694 messages |
| 2010年12月14日 15:34:20 | KevinH | create |
|