Looping workflow due to long filename [SOLVED]

Questions and answers on how to get the most out of FFAStrans
Post Reply
crispyjones
Posts: 48
Joined: Wed Dec 27, 2017 3:21 am

Looping workflow due to long filename [SOLVED]

Post by crispyjones » Tue May 05, 2020 11:42 pm

Ran into an interesting issue that took me a bit to figure out and may help others. A user dropped in a twitter url with an unusually long name in to my "webvideo" workflow. The job showed failed in the webui but the downstream system still got the expected output file. Additionally the workflow repeated the job every 30 seconds until I manually deleted the file from the watch folder. What I found was that the twitter url was 240 characters long *but* when the UNC path of the workflow watch folder was added it became 278 characters long. This 278 character filename is what the Command Executor attempts to delete with %comspec% /c "del /f /q "%s_original_full%"" command. Unfortunately as it is longer than 255 characters it fails, and since I had "forget missing files" checked it repeated this process every 30 seconds until I caught it.

Next question, any smart people know of some command switches to add that can get around that? I am thinking that using the windows short ~ file naming might work but can't figure out how to do that.
Last edited by crispyjones on Fri May 08, 2020 10:03 pm, edited 1 time in total.

emcodem
Posts: 586
Joined: Wed Sep 19, 2018 8:11 am

Re: Looping workflow due to long filename

Post by emcodem » Wed May 06, 2020 7:16 am

Hey crispy, always good to hear from you!
I know this problem about too long filenames when using UNC Paths. For me it was always about using different UNC Shares to access the same folder:
  • Option 1: The User uses a short Share name like: \\server\shortshare
  • Option 2: The User uses a mapped drive letter like: Z:\
  • You (or ffastrans) uses the full path instead: \\server\allshares\shortshare


Explained: there are multiple shares on the server, some are pointing to subfolders in existing shares.

This way, the OS of the user does not recognized that it created filenames longer than 255 characters. - It is a question of perspective.
So what you can do is to use the same "short" sharename than the user.
If this is not possible, you just create new "short" sharenames like \\server\a - pointing to \\server\allshares\shortshare

Would that work for you?

I believe using short names would not work as well, the delete would still fail, can you test this on commandline? just use dir /x to get the shortname and make sure you use exactly the same path/sharename that ffastrans would use

Also i would be interested if the new custom processor "files delete" works with filenames longer than 255 chars but from experience i fear nothing works beside using a different Sharename or NTFS junction point.

crispyjones
Posts: 48
Joined: Wed Dec 27, 2017 3:21 am

Re: Looping workflow due to long filename

Post by crispyjones » Thu May 07, 2020 2:24 am

Thanks for the ideas. Things are getting a bit strange. I copied the workflow to my desktop PC so I could run tests without disturbing the production machine. The only difference is I run FFAStrans as an exe and not as a service on my computer and now the delete node isn't having any problem deleting files in UNC paths. The urls are the same long names the other machine couldn't delete, I even deliberately made a ridiculously long folder name that put the character count over 300, and it has worked every time. When I find out more I'll post.

emcodem
Posts: 586
Joined: Wed Sep 19, 2018 8:11 am

Re: Looping workflow due to long filename

Post by emcodem » Thu May 07, 2020 9:15 am

Hm, that nearly sounds like you are working with a filesystem driver that is configured on a per-user basis... but thats only a very small shot in the dark

crispyjones
Posts: 48
Joined: Wed Dec 27, 2017 3:21 am

Re: Looping workflow due to long filename

Post by crispyjones » Fri May 08, 2020 9:50 pm

Apparently Windows 10 now supports long file/path names>260 characters with a minor registry tweak. Found this article and noticed it was enabled on my dev machine but not on my production machine. I changed the registry key mentioned, changed the monitor back to 'forget missing files' and the two twitter urls were processed and deleted without issue!
Last edited by crispyjones on Mon May 11, 2020 9:03 pm, edited 1 time in total.

admin
Site Admin
Posts: 1442
Joined: Sat Feb 08, 2014 10:39 pm

Re: Looping workflow due to long filename [SOLVED]

Post by admin » Sat May 09, 2020 4:42 pm

That's great to know, crispyjones! Thanks for sharing :-)

-steinar

Post Reply