Bug in unit Zipper?

[bonmario]

Hi,
see the attached project.

If i try to unzip file "content.xml" from "DocWithoutPassword.odt", all is ok.
If i try to unzip file "content.xml" from "DocWithPassword.odt", the file is create but i's empty.

The 2 document is the same, but "DocWithPassword.odt" is protected with a password "MyPwd". This means that the file "content.xml" is encrypted.
If i try to unzip it for example with 7Zip, all is ok,

It's a bug?

Thanks, Mario

[Edited to remove defunct attachment]

[lucamar]

Not exactly a "bug" but, IIRC, a missing feature. I'm not entirely sure but I kind of remember that it can't be used with password-protected archives. In fact, if you look closely you'll see that there is no way to set a password anywhere.

[bonmario]

Archive is not password-protected.
You can open it with 7zip, and extract files, without password

[lucamar]

Are you using trunk Lazarus? I tried to open your project with Laz/FPC 2.0.10/3.2.0 and it came up empty. If you're using trunk there is, IIRC, an option to "save project files as compatible as possible" or something like that; use it and re-post your project, will you? Otherwise I'll have to rebuild it to test here.

But, yes, you're right; it's not the "zip" which is password protected but (IIRC) the text contents which are encrypted. I'd forgotten that

[bonmario]

Hi,
i'm using "Lazarus 2.1.0 r64045 FPC 3.2.0 i386-win32-win32/win64"

I've enabled option to "save project files as compatible as possible", and i have reuploaded it here.

Thanks, Mario

[lucamar]

Thanks! I have now been able to test and you're right: 7zip (through Engrampa, in my case) is perfectly able to extract the file but TUnziper just creates an empty file ... I don't know why, though; it's a normal zip so it shouldn't fail.

That is, unless there is something strange in the header of either the archive or the file ... or both, of which 7zip (and presumably other archivers) are aware. Which I can't test here

I'm sorry I'm unable to offer more help.

[marcov]

I tried with infozip, and it generates a scrambled file

[bonmario]

It's right, because "the document" is protected with a password.
If you do it wit project attached, the file "content.xml" unzipped have size = 0

Thanks, Mario

[rvk]

The problem is (I think) that Zipper doesn't read certain zips where the size is AFTER a data-chunk and not in the header.
It should implement this in ReadZipHeader.

From https://en.wikipedia.org/wiki/ZIP_(file_format)

Data descriptor
If the bit at offset 3 (0x08) of the general-purpose flags field is set, then the CRC-32 and file sizes are not known when the header is written. The fields in the local header are filled with zero, and the CRC-32 and size are appended in a 12-byte structure (optionally preceded by a 4-byte signature) immediately after the compressed data:

So in certain cases, the Compressed_Size and Uncompressed_Size isn't known at point of compression. So the header fills it with 0. Then after compression it writes the Compressed_Size and Uncompressed_Size AFTER the compressed data.

You could see that from the BIT_FLAG

Without password

record LOCAL_FILE_HEADER_TYPE {
  SIGNATURE = 67324752,
  EXTRACT_VERSION_REQD = 20,
  BIT_FLAG = 2048,
  COMPRESS_METHOD = 0,
  LAST_MOD_TIME = 18920,
  LAST_MOD_DATE = 20880,
  CRC32 = 14388951,
  COMPRESSED_SIZE = 1147,
  UNCOMPRESSED_SIZE = 1147,
  FILENAME_LENGTH = 8,
  EXTRA_FIELD_LENGTH = 0}

With Password
 

record LOCAL_FILE_HEADER_TYPE {
  SIGNATURE = 67324752,
  EXTRACT_VERSION_REQD = 20,
  BIT_FLAG = 2056,
  COMPRESS_METHOD = 0,
  LAST_MOD_TIME = 18552,
  LAST_MOD_DATE = 20879,
  CRC32 = 0,
  COMPRESSED_SIZE = 0,
  UNCOMPRESSED_SIZE = 0,
  FILENAME_LENGTH = 8,
  EXTRA_FIELD_LENGTH = 0}

2048 = 100000000000
2056 = 100000001000 <- offset 3, 0x08 = 1

So the file with password has all the compressed and uncompressed sizes AFTER the data.
Zipper only reads headers IN FRONT of the data.

[bonmario]

Ok.
Thanks, Mario