Can't see decrypted drive contents when using 1.3.4

Help
1

I have a drive that was encrypted using 1.3.3.

With the 1.3.3 client it works fine. The virtual drive mounts and I see the contents.

With the 1.3.4 client I don’t. The virtual drive mounts but the contents are not there.

On Windows 10. Using the java client, with the latest 1.8 jvm.

PS. Thank you for making this software. It is awesome! :slight_smile:

2

Hi @jschlade, thank you for the report! Just received another email with the same issue. Do you use the JAR file or did you install Cryptomator (using our installer)?

3

I just did some tests and I’ve reported a bug on GitHub.

4

Hi,

The window installer just wraps the java app. Nice architecture BTW. Need to look at the code. Wondering if the UI uses JavaFX or Swing. I’m sure it’s the same architecture for mac and Linux.

I use the executable jar file too.

IMHO - Not testing decrypting and then inspecting files from previous version vaults seems like a big hole in any unit testing that’s being done against this code base.

Thanks

Just looked at the defect. Interesting…

Notes

  • I was unable to reproduce this bug on Windows with the “installed version” of Cryptomator 1.3.4.
  • I was unable to reproduce this bug on macOS (didn’t test Linux).
  • It only seems to happen if there is at least one folder involved. I was unable to reproduce this bug if there was no folder involved.
5

Yes, but it comes with its own bundled JRE. The weird thing here is that Cryptomator 1.3.4 was built with JDK 8u162 so I don’t know why it behaves differently. But I actually recognize the error in the stack trace (has to do something with JDK 8/9 compatibility). Will have to wait for @overheadhunter to look at it, he may know what’s going on.

It’s JavaFX. :slight_smile:

We tested Cryptomator 1.3.4 on multiple machines with the “installer version”. Couldn’t really predict that the JAR file would be that different. :wink:

6

hmm… googling exception, found: https://github.com/plasma-umass/doppio/issues/497

"This problem also happens when you build the software with JDK 9 with target JDK 8, because in JDK9 ByteBuffer.flip() returns a ByteBuffer… It used to return a Buffer in JDK8.

And then you try to run this on JDK8 you get exactly this error.

Java-Workaround: Just cast your ByteBuffer to Buffer before calling flip()… i.e. ((Buffer)byteBuffer).flip(). Then you can compile your project with JDK9 and have it running on JDK8.

Note: This is not really related to this project, I only use pure java. But I found this problem report and thought you might be interested in a workaround for this."

And there’s other interesting comments on how to correctly use the java9 jdk to build java8 compatible code…

7

Thank you for your input. We found the same issue in the past days, that’s why I recognized this issue. :smiley:

In the meantime, we found out how to fix it and we’ll release a new JAR soon (probably after the Easter holidays). The fix depends on:

8

“We tested Cryptomator 1.3.4 on multiple machines with the “installer version”. Couldn’t really predict that the JAR file would be that different. :wink:”

Very strange this didn’t show up with the embedded jre of full install? I believe the installer uses 1.8.0_162 and I’m using Sun’s 1.8.0_162 jre 32-bit… doesn’t seem to be a 32 bit or 64-bit issue either.

What does the embedded jre do that’s so different? Probably need to add coverage for this edge case.

9

I had the same problem with the Java version of Cryptomator 1.3.4 and JDK8 using Linux Manjaro OS. But Cryptomator 1.3.3 still works fine.

10

Issue is fixed. To be released soon (jar-only release).

2 Likes
11

Many thanks, Cryptomator-1.3.5.jar works super with Linux Manjaro… :smile:

1 Like
12

Where can you find the release notes for each version?

13

Here: https://github.com/cryptomator/cryptomator/releases