I am terribly sorry: I introduced a regression in the 3.0.1 release which needed immediate attention. For those of you who updated to 3.0.1, please download and install
the 3.0.2 release.
Here is what happened.
Internally, a .CRDOC file is just a plain ZIP file, with several components: the document data, a preview, images and possibly some embedded fonts. We are relying on the open source
#ziplib library to read and write the file.
In the process of migrating our whole source tree, we upgraded also the version of #ziplib, not realizing that some subtle implementation details changed. I still do not know if I have hit a bug in #ziplib 0.86.0.518 or if it is an error in the way I use it which was at the root of the problem.
For the curious, the
ZIP file format consists of the concatenation of file entries, followed by a general directory at the end of the file. Every file entry can specify the raw and compressed size of the associated file data. The broken version of Creative Docs .NET somehow generated files where the compressed size was not properly specified. #ziplib therefore cannot naturally move from one item to the next, and as a result, the extraction fails. Curiously, Windows still manages to open the broken .CRDOC files (after they have been renamed to .ZIP). I suspect it uses the general directory to access the file entries when the compressed size is not available in the file entries.