Skip to main content

Problem

The problems are caused by the underlying functionality of how FME Core downloads the email attachment and with the default FME Server Cleanup setup

 

One of the functionalities that will be broken with this, is, for example, Backing up the FME Server. Resulting in a `COM.safe.fmeserver.configuration.migration.FMEConfigurationException: java.io.FileNotFoundException:` for the attachment.

 

This is reproduced with the following steps:

  1. Create an Automation Trigger of an email (SMTP)
  2. Define a custom "Download Attachments To (optional)" path. Preferable something that is not covered by the default FME Cleanup, like`$(FME_SHAREDRESOURCE_DATA)/custom/mail/received/`
  3. Make sure this is triggered and the attachment is downloaded to the location
  4. Notice that the FME Server seem to create symlinks in `$(FME_SHAREDRESOURCE_DATA)/custom/mail/received/` which are linking to the default mail attachment resource `$(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments`
  5. Wait for the default "Delete_EmailAttachments_Files" Cleanup task to be triggered
  6. Try to create a backup and notice an error related to files not being found

 

What happens?

Because the FME Server seems to not download the attachments directly in the folder but instead creates a symlink to `$(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments`, it creates the potential of becoming a dead symlink. This happens because the "Delete_EmailAttachments_Files" Cleanup task cleans the `$(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments` where the custom path (the symlink) is not cleared.

 

Resulting in: "Custom Path (not cleaned) --symlink--> $(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments (cleaned)"

 

Questions

  1. Is there a way for FME Server to simply not create symlinks and instead directly place the attachment in the given custom path
  2. If not, what would be recommended way to deal with this? As a workaround, I recommended the custom path to simply be `$(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments` so the cleanup also covers any symlink. Though this feels like a workaround which we have to remember.

 

Hi @smol​ ,

 

I'm sorry that you encountered this issue. It looks like we introduced the use of symlinks with the SMTP Email attachment in FME 2019.1 and newer to resolve a separate issue and unfortunately, this did have some unforeseen repercussions across other functions in FME Server. The problem with creating a backup has been fixed for FME 2020.0 b20158 and newer.

 

I'm in the process of setting up a test environment in FME 2019 so that I can attempt to reproduce the issue and try and find the best workaround for you, I'll let you know what I am able to find. Please note that if you leave the 'Download Attachments To (optional)' field blank it will default to use $(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments as the file path so you shouldn't have to set this every time, but depending on how you are using these files you may wish to change the System Clean Up Task so that they remain on your system for longer than 1 day.


Hi @smol​ ,

 

I'm sorry that you encountered this issue. It looks like we introduced the use of symlinks with the SMTP Email attachment in FME 2019.1 and newer to resolve a separate issue and unfortunately, this did have some unforeseen repercussions across other functions in FME Server. The problem with creating a backup has been fixed for FME 2020.0 b20158 and newer.

 

I'm in the process of setting up a test environment in FME 2019 so that I can attempt to reproduce the issue and try and find the best workaround for you, I'll let you know what I am able to find. Please note that if you leave the 'Download Attachments To (optional)' field blank it will default to use $(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachments as the file path so you shouldn't have to set this every time, but depending on how you are using these files you may wish to change the System Clean Up Task so that they remain on your system for longer than 1 day.

Thanks for the insight. For now, we confirmed that it works when we simply do not set a custom path but use the default `$(FME_SHAREDRESOURCE_SYSTEM)temp/emailattachment`. This way the cleanup is both in sync with the symlinks and the actual files.


Reply