"Interactive content" container field on a layout prevents externally stored PDFs from being deleted... (8 Comments)

Issue report by Kepi

Product

FileMaker Server

Version

13.0.1

Operating system version

Mac OS X 10.9.1 (13B42)

Description of the issue

In a server-hosted FileMaker file, when a layout has a container field on it that is set to "Interactive content", removing the file from the container (either by clicking into the field and hitting the delete key, or by a Set Field [ TheContainer ; "" ]), the file won't be immediately removed from the server.

Initially I thought it wasn't removing the file at all, but while typing this report up I saw the documents I was testing with, and their containing folders inside RC_Data_FMS, finally get removed from the server. So rather than not being deleted at all, there was a delay of about 8 minutes until the server cleaned up after itself.

If the container's display mode is set to Images, removing the content from the container field immediately removes it from the server's filesystem.

Steps to reproduce the problem

1) create a FileMaker file with a container field set to external open storage
2) on a layout, place the container field and set its Data Formatting to "Optimize for Interactive content"
3) host the file on FileMaker server
4) open the file and create a new record
5) insert a PDF into the container field. It will appear in the Data/Databases/RC_Data_FMS folder hierarchy
6) delete the PDF from the container and commit the record

Expected result

File is immediately removed from where it lives in Data/Databases/RC_Data_FMS

Actual result

File hangs around on the filesystem for anywhere between 10 seconds and 8 minutes in my testing, leaning more towards the longer duration.

The server does eventually clean up the files and containing folder structure, it's just greatly delayed.

Exact text of any error message(s) that appear

Not applicable.

Configuration information

I've only seen this happen with PDFs so far (I suspect it will happen with any content that will actually be displayed differently between an "Images" container and an "Interactive content" container).

For example, removing a screenshot from an "Interactive content" container field removes it from the filesystem on the server immediately.

I'm guessing the FileMaker client displaying the PDF keeps a reference to the file due to it being fully loaded, and that reference doesn't get cleared right away when the file is removed from the container because the PDF is still "open" in some fashion.

Refreshing the layout, navigating away from the record, and even quitting FileMaker client doesn't force the filesystem removal to happen.

Workaround

None.