Automation: Custom email attachment download patch results in dead symlinks

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.