Error with wf when _ and - in name?

[lue3099]

Hello,

Windows Server 2022 Datacenter (21H2), OS Build: 20348.768
FFAStrans: 1.4.0 (The error was also present in 1.3.1 as well)

I have a workflow that errors when the name has _ and - characters, I think?

Code: Select all

Got error code 6 - The handle is invalid, when trying to deliver <path to deliveries>

"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.mxf" = Works fine
"aaaaaaaaaaaaaa_aaaaaa-aaaaa_-_aaaaaaaaaa-aaaa_aaaaaaaaa.mxf" = Doesn't work

The workflow in the attached zip is a recreation of a production workflow.
I'm sure it doesn't need to be as complex as I made it, but I wanted it to be as similar.
The holds are dummy nodes to be as similar to the actual workflow layout.

The zip that contains a screenshot, the workflow export and logs.

I do have "LongPathsEnabled" in the registry of this machine.

What is causing the error?

ffastrans_name_error.zip

workflow, screenshot and logs

(1.54 MiB) Downloaded 11 times

Regards,
Lue.

[emcodem]

Hi Lue,

thanks a lot for the exhaustive reproducing and logs you did, without it i would not have had any chance to debug the issue.

Look at how webinterface displays your workflow execution.

Untitled.jpg (33.17 KiB) Viewed 260 times

The little "2" Symbol on the top left side of your "write text" processor means that it is being executed 2 times. One time it works and the other one which is trying to create the same text file in the very moment when the first one is doing it, fails.

The reason for this is described here (there is a difference between reality and what you see in the workflow canvas).
viewtopic.php?p=3565#p3565

[lue3099]

Ahhhh thanks emcodem, makes sense. Although, It is weird, does it do it with all names? Because it seems to only do it with those symbols. Without the symbols, seems to always work? Do you know why that is?

[emcodem]

So i was able to reproduce the issue but only like 1 out of 10 times. This would make sense because the 2 paralell "write text" processors need to be executed at the same time (e.g. millisecond) but of course the slower the harddisk is, the bigger is the timeframe where this can happen. The faster it is, the more unlikely it might be to happen.
If it is like i think, it has not much to do with the symbols, well maybe it takes longer for windows to do something with the file when it has _- in the name, who knows...

What i am saying is that it appears to be kind of accident, sometimes happens, sometimes not, depending on the performance and load of the machine.
You can of course just insert some "catch error" processor (e.g. a populate vars that does nothing but input pin is set to "execute on error") in order to catch the error which allows the rest of the workflow to go on.

[emcodem]

Btw, we are not yet finished and it appears that i was wrong with my assumption that the error is caused by write text file processor. Also i can reproduce it even with copies of a.mxf in the watchfolder, so i currently believe it is not anyhow bound to the filename.

[emcodem]

Looks like our master of desaster found the bug. It is a funny problem inside ffastrans where after the write text processors in your example, we delete the "job work" directory and write the final log file.But the job continues to run in ghost mode.
As the job_work dir contains the mp4 encoded file which you want to deliver by move, this move (deliver file proc) fails, this is the error msg you see.
Still a lot of stuff that i wrote above applies, e.g. the issue will happen kind of accidently, depending on the load of the machine and filenames do not really seem to make the error more or less often occur.

You can workaround by "keep work folder on completion" in workflow->properties->Maintenance menu. This leads to the work folder staying for some time e.g. 2 weeks or so before it is auto deleted. If you want that faster, you can add a cmd processor at the end of the job with this content:

Code: Select all

%comspec% /C "rd /s /q "%s_job_work%""

This way only 1 small file will remain in the work folder and even this one will be automatically deleted after 2 weeks.

Steinar accepted this as a bug or bad design and will fix it. There should be a bugfix release update for 1.4 relatively soon, maybe a few months...