High Sierra and Node Out zip files


Thanks a lot for the update. Hoping to get the fix soon :)

Kind regards



I have exactly the same problem with "Tabel write" and "Tabel read". If I write a table with about 25mb and I try to read it afterwards, I get confusing errors like:

Execute failed: invalid code lengths set

Execute failed: invalid distance too far back

Execute failed: invalid block type

The worst point is, that those files can not be read with another KNIME version on Windows. So it means, that the written files are kind of damaged, which is a big problem!



Yes indeed. But it's clearly a bug in High Sierra. We have created a minimal Java application that reproduces the problem on High Sierra but works fine on any other operating system including Sierra. We have opened a bug report at Apple but didn't get any response so far.


i also encounter problems that Ralph mentions. Sorry to say this but to be on the safe side we should stop using Knime on HIGH Sierra... In case on not signaled inconsistencies elsewhere.

Maybe this should be told to HIGH Sierra users so that they don't get into problems. And to Sierra users TO NOT UPGRADE NOW....

On my side, i am downgrading back to Sierra one of my Macs, but it's lot of work since we must erase the whole HD before installing Sierra : so all programs have to be installed again (not only Knime).

Would it be possible to get an estimate date from apple for a fix ?

Thanks in advance



We'll add a warning to KNIME's welcome screen that there are issue on the newest MacOS. 

We can't comment on when Apple releases a fix. It seems others have run into the same issue, too: https://stackoverflow.com/questions/46539453/tomcat-with-compression-enabled-causes-error-on-os-x-high-sierra (we believe it's the same issue: zip compression in java programs)

We are one step further, it's a bug in the zlib library that is shipped with High Sierra: https://github.com/madler/zlib/issues/305

This was remedied with this commit. Can someone verify?

Apparently that didn't do it. Can someone provide a sequence of zlib calls that reproduces the issue? Possibly from the example program in the issue on github?

The problem has been found, and it is in the JDK. Here is the fix, written by xuemingshen.

The bug in the JDK is that compressed data returned by zlib's `deflateParams()` is being discarded. This results in corrupted compressed data.


In Java noob words, how can this fix be applied?

Thanks in advance!

We are currently looking into providing a patched version of KNIME that will circumvent the critical method calls (changing the zip compression level between entries). Give us few more days to put it online.


Thanks for the follow-up :)

Kind regards


We added the fix to the nightly build that you can get form here. Could someone else test that quickly, too, and then we backport it to 3.4.x.



I am performing the test, running 3.4.1 and 3.5 on same data. At this stage, i don't see any bug. And issue seems to be fixed. I have a bunch of big sets of data to work with in the coming day so i will keep you updated.

Many thanks for your work and clear information on all this.

Kind regards

The problem hasn't been fixed for 3.4.1 yet... either the problem has rectified itself (which almost never happens), you didn't run the relevant code path or are screwing up KNIME installations...

You should be able to easily reproduce the problem by just creating a simple workflow, executing it and then saving the executed workflow and reopening it. It should then show an error message.

Does it?


what i was saying: in order to correctly test, I have use same data on 3.4.1 which is not fixed and on the 3.5. Difference is clear : no bug on 3.5 while bug is there on 3.4.1, for both brand new or old workflows. I keep working with 3.5 and if I fin anything I will let you know.

kind regards



Hi Bruno,

Apologies for the confusion! Thanks.

I had an email exchange with Philipp and he confirms the fix also. We'll be back-porting and releasing a 3.4.2 the week after next week.


Is there a chance for a solution for the ZIP problem in the near future? Actually the warning is not very specific and just links to a long list of (seemingly) minor issues with High Sierra. The hint does not say that an update would basically stop KNIME from working on Macs with High Sierra (you can't store any nodes or KNIME tables at all).


We released 3.4.2 and this includes some extra code that will bypass the critical system call. This will make saving KNIME workflows slightly slower but it will workaround that problem.