I have a container field that's configured to use External Secure storage in the hosted file. When I sync a PDF that's stored in that field in the mobile file, it gets pushed up to the hosted file without any problems. But if I then modify that record on the hosted file, for example by changing a value in one of the text fields, and then sync again, the record gets pulled down to the mobile file, but the container data (in the mobile file) gets corrupted.

 

When the container data is valid, GetAsText ( MyTable::MyContainerField ) returns something like this:

 

remote:Transfer Request.pdf
PDF :Secure/0D/63/4D03FB8E/064665D1/C08FFD43/C64C

 

After the sync, it returns just this:

 

C64C

 

Changing the storage from Secure to Open fixes this problem, but the documents contain sensitive data, so that won't work. A workaround would be to embed the documents internally, but it would be better to have them stored externally.

 

The Open Issues page talks about issues with compressed containers. Is that what's going on here too?

Hello.

 

It appears as though the problem that we have seen with compressed containers also applies to external, secure containers.

 

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 ends up encoding 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 uncompress or decrypt it. As a result, functions that reference the container return incorrect values.

 

 

Thanks.

 

-- Tim

Tim,

 

This post seems to explore the issue with compression and base64 decoding as well:

 

http://fmforums.com/forum/topic/92243-marking-a-container-as-compressed-as-insert-file-can/

 

 

Are there any issues that you are aware of regarding the reliability of open stored containers?

 

I've been searching, but do seem to remember Wim Decorte remarking that there is a data reliability issue. I'm hoping he was simply warning us not to modify the container data from outside of FM.

 

Thanks,

Barbara

Barbara,

 

FWIW, syncing open stored containers using EasySync seems to be working fine for me.

mkos - good to know.