OpenOffice-created zip archives sometimes use the "data descriptor record" to store checksums and lengths. getLocalFile now checks the general purpose bit flags to see if there is a data descriptor record; if there is, it ignores the compressed size field and instead reads data until the data descriptor record is encountered. This patch should fix problems reading ODS and other OpenOffice created zip archives. Thanks to Joel Lehtone for calling the problem to my attention.
+ getFileHeader now returns a Data.Map structure instead of a list [(Word32,ByteString)]. + The inefficient CRC32 computation has been replaced by an efficient one from Kirpichov's new 'digest' package. + Removed Data.Hash.CRC32.GZip + Version bump to 0.1.1.2.
Patch to zipifyFilePath from JP Moresmau. Previously, when creating a zip file using absolute paths, a slash was inserted between the drive (c:\) and the first directory. So other tools could not open the generated file.
+ Shorter names: ZipArchive -> Archive, ZipEntry -> Entry + Compress/decompress functions are no longer exposed; they shouldn't be needed since toEntry and fromEntry handle compression and decompression + Added toEntry, which creates an entry with a specificed path, timestamp, and contents + Simplified readEntry (using toEntry), added verbose options + Modified writeEntry to handle directories correctly; added verbose options + Simplified addFilesToArchive using the new readEntry + Simplified extractFilesFromArchive using the new writeEntry + Modified Tests.hs and Zip.hs accordingly
Also, return a bytestring rather than an Either, and raise an exception if CRC32 mismatch.
Define Eq for ZipArchive so that two epoch times that convert to the same MSDOS datetime are regarded as equal.
Don't expose MSDOS datetime conversion functions in API.