FileMaker: Issues With Compressed and Secure External Containers
During beta testing of FMEasySync, we discovered that some containers were not being properly synced. After some investigating, we found that this bug would manifest if the "compress" option was used when inserting a file into a container.
This morning, after receiving a bug report via EasySync's online forum, I confirmed that the problem manifests with external, secure containers containers as well.
From what I can tell, when you Base64 encode a container field, FileMaker does not first check to see if the container is compressed or secure. As a result, it encodes the compressed or secure version of the container. If you then decode that value, the result is not the original container. I have tried a few work-arounds for this (including setting up a proxy for the original container field), and all have failed.
At first, I thought that maybe this was a bug in FileMaker's Base64Encode function. However, I'm seeing similar behavior when using the "BE_Base64_Encode" function that is available in the BaseElements plugin, as well as the "Container.GetBase64" function that is available in the Monkeybread MBS plugin. So the problem seems to be further upstream. It is as if when FileMaker retrieves the compressed or secure container, it does not immediately decompress or decrypt it. As a result, functions that reference the container return incorrect values.
Unfortunately, there's not much that we can do about this problem. It seems to be an issue with FileMaker itself.