Frends.SFTP.DownloadFiles temporary file naming options

Downloading files that have incompatible characters in their filename is problematic, as DownloadFiles task forces user to perform renaming the file in the source in order to avoid issues in temporary folder level. User has option of choosing a new name for the downloaded file, so why not use it (or even random string) as temporary filename? Example of trigger parameters of DownloadFiles task: { "source": { "Directory": "/", "FileName": "FG202023-06-1609:48:51.conf", ... }, "destination": { "Directory": "\\\\nas1\\backup", "FileName": "FG202023-06-16094851.conf", ... }, "options": { "RenameSourceFileBeforeTransfer": false, "RenameDestinationFileDuringTransfer": false, ... }, } Snippet from operation log: 13.23.45Z: GetFile: Downloading temporary source file FG202023-06-1609:48:51.conf to local temp folder C:\Users\frends.service\AppData\Local\Temp\p3s5e3tb.k4e 13.23.45Z: File transfer failed: Failure in GetFile: File 'FG202023-06-1609:48:51.conf' could not be transferred to '\\nas1\backup\FG202023-06-16094851.conf'. Error: The filename, directory name, or volume label syntax is incorrect. : 'C:\Users\frends.service\AppData\Local\Temp\p3s5e3tb.k4e\FG202023-06-1609:48:51.conf'. FG202023-06-1609:48:51.conf is an invalid filename to be used in Windows, and that's why we have set a new filename to be used in destination.FileName, but apparently Frends.SFTP.DownloadFiles still tries to use source.Filename when it downloads the file to temporary folder. Would it be possible use destination.FileName as filename in local temp folder (fallback to source.FileName, if destination.FileName is not specified)? This way users could workaround issues that raise when different systems have different filename requirements. For example Azure Storage account Blob container allows double colons in filenames, and when it's accessed via SFTP, the files cannot be downloaded to Windows platform unless files are renamed on the fly. Setting RenameSourceFileBeforeTransfer to true will resolve the issue, but it leaves open another possible issue where source file is renamed, something goes wrong later in the process, changes need to be reverted and renaming the source file back to original filename fails (for example network issues). Next task execution might not find the same source file again depending on how strict the source filename filtering is.