Looping workflow due to long filename [SOLVED]

[crispyjones]

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.

[emcodem]

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]

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]

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]

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!

[admin]

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

-steinar