Inconsistent behaviour when trying to append() incorrect data types

[davidknoll]

So I needed to use this module, despite certain shortcomings, because it was the only one I found that supports passwords, and we're dealing with exporting personal information in our app. I note that when appending a file, you're supposed to provide a String, Buffer or Uint8Array as the data argument. However, when debugging, I noticed the following inconsistent behaviour when given edge-case or incorrect arguments:

• With mz.append (with a password specified):
  • where data is given as one of undefined, null, 0 or 1 (numbers), false or true (booleans), or {} (empty object), it throws an exception right away (expected, those don't make sense as a file defined as an array of bytes)
  • where data is given as one of '' (empty string), or [] (empty array), doesn't throw an exception (expected, those make sense to me as representing an empty file)
  • where data is one of [{}, {}, {}] (array of empty objects), [{a:1,b:2},{a:11,b:22},{a:111,b:222}] (array of objects with consistent properties), [{a:1,b:2},{c:11,d:22},{e:111,f:222}] (array of objects with inconsistent properties), doesn't throw an exception (unexpected, they don't make sense as a file defined as an array of bytes)
• Listed in the archive (when I try 7z l test.zip):
  • The mz.append attempts that didn't throw an exception, where that made sense to me, resulted in a 0-byte file added to the archive (expected)
  • The mz.append attempts that didn't throw an exception, where that didn't make sense to me, resulted in a 3-byte file added to the archive (matches the length of the array provided, but still doesn't make sense as a file)
  • The mz.append attempts that did throw an exception, did not result in a file being added to the archive (expected)
• Extracting the archive (when I try 7z x test.zip):
  • The 0-byte files, that make sense to me, fail to extract with a bad CRC (ie the zip is corrupt) when a correct password was used. (This isn't the same error that appears when I actually try an incorrect password.) I still see actual 0-byte files extracted, despite the error.
  • Those same 0-byte files, extract successfully if no password was specified in the first place when adding them.
  • The 3-byte files, that don't make sense to me being added, extract without errors, and consist of 3 bytes of 0x00. (This is the same whether a correct password was specified, or when no password was specified in the first place.)

[davidknoll]

What gave rise to this investigation by the way:

• I have an array of objects, coming from a database query. I use another library to turn this into a CSV file, returning a long string, which should then be suitable to add to the zip.
• If the query returns no records, the CSV stringify returns an empty string. (It can't even provide a first row with column headings, if it doesn't see any objects in the array to extract the keys from.)
• Adding such an empty file to the zip, using a password, gives a corrupt zip.

And another thing:

• In my development instance, the amount of records I end up extracting isn't many, but the zip is padded out to 64KB with a bunch of zeroes. I get the following message when I extract/test/list it with 7z:

WARNINGS:
There are data after the end of archive
Physical Size = 835
Tail Size = 64701