FFAStrans forum

Hello dev team
I have an import workflow processing variety of non-professional A/V formats and transcoding them to professional IMX50 or XDCAM HD422 codecs. Almost the last step in the workflow is a command executor with simple command inside: %comspec% /C "del /f /q "%s_original_full%"" ... i.e. it should delete the source file.
There are two more processors in the workflow after this "cleanup processor" - Send email" (in case of any error in WF) and "Set State to Error" command (%comspec% /C "exit 1")

On 7.6.2021 at 20:47 an execution of this workflow failed because the value of variable %s_original_full% got lost!
- on the beginning its value was \\pr-isilon\xxxxx\yyyyy\zzzzz\RZ_domaci_FCB\Skype_Hutt.mp4 ... i.e. the UNC path of the file detected by watchfolder node
- but on the end its value was empty - Because of that a "cleanup processor" executed command C:\Windows\system32\cmd.exe /C "del /f /q """ attempting to delete system32 files ... fortunately it failed:
C:\Windows\system32\69fe178f-26e7-43a9-aa7d-2b616b672dde_eventlogservice.dll
Access is denied.
C:\Windows\system32\6bea57fb-8dfb-4177-9ae8-42e8b3529933_RuntimeDeviceInstall.dll
Access is denied
etc...

The machine processing this particular workflow is running Windows 10 Pro (64-bit). The input file was stored on Isilon X200 cluster running OneFS 8.0.1.0.

Could you please analyze the logs I will send you in PM and tell me the root cause of the issue.
Thanks

Hi Silicon

Ok, the first thing is that the problem with your command trying to delete the system32 folder has been addressed in the upcoming 1.2.1 version. This behavior was because the default work dir was set to system32. Now it's set to a unimportant temp folder.

Second, I would like to see those logs

-steinar

Hi -steinar
I've sent you requested logs via PM.

Could you share with us estimated release date of vesrsion 1.2.1?
Thanks

Hi,

The release of 1.2.1 has been delayed more than I anticipated but it's very close to release now. I'm reluctant to give any date but....it's soon

Anwyay, for other forum members; I've investigated the issue with Silicon and has come to the conclusion that this is a very freak accident. It's hard to know the direct cause of it and also difficult to find ways to prevent the issue. But it had nothing to do with the %s_original_full% not being populated. This was just a consequence of the issue. However, the BIG problem here was that the command Silicon used to remove the original file tried to remove the "System32" folder, which is REALLY bad. This particular problem IS resolved in the upcoming 1.2.1 version. So even though the initial issue is unknown, FFAStrans now set the working direcory of the command executor to a temp folder instead of the system default "System32" dir.

Thanks again for reporting!

-steinar