TftpPut - ... is not a valid file path

[cmills]

I seem to be getting this error in cases where the remote SFTP server is parsing for and removing files near-instantly when they are received. My guess is that this somehow fools the TftpPut component to thinking the location is invalid. In the past when I've encountered this, the files seem to FTP just fine, but the component throws an error. I've learned to ignore this on a different process that is verified independently, but I'm needing to rely on the success/failure of this transfer, so I really need to work this out if possible.
Here is the error I'm getting.

[Anonymous]

Of course not. This message is correct.
/../anything/...
means: Go to the root (/) and than go to its parent (/..) but root does not have a parent.

[cmills]

Sorry, I chose a poor screenshot to use.
It also fails when the folder is entered as:
"Input/Test"
"/Input/Test"
"./Input/Test"
And I am positive /Input/Test is the correct folder structure.
I have this same issue with an SFTP that I know to work despite the error, but I just need to stop getting this error.

[cmills]

As an aside, I do find it amazing that I can't easily find search results for this, which leads me to believe there should be some sort of simplistic solution that I'm missing. I've had this issue on every setup I've done where the remote SFTP site removes the file immediately upon arrival.
Also as a note, I've tested uploading files that aren't removed immediately (they don't match the naming structure that's being waited on), and the FTP works just fine. It's clearly the removal of the file that's causing me issues, but I just have no clue what to do about it.

[Anonymous]

How does the the process removing the files know when the file transfer is complete? I would guess, that it doesn't, or at least not correctly, since you a receiving these errors. It appears the sender is not finished with its operations before the file is moved. I would guess that is a very dangerous situation with corruption probably occurring or will occur when your luck runs out. This is why people use trigger files or at least stat the file for a number of seconds (also not super safe) to ensure the transfer is complete. The process moving the files needs to be corrected to ensure transmission is complete before it moves the files away.

[cmills]

I thought that would be an issue, but after have the same issue when setting up with Wells Fargo for NACHA transactions, I figured it's just something I would have to deal with. Is this really as rare of an situation as it seems to be? If they refuse to change their processes are there any suggestions for procedures to put in place?
Right now my only idea is to capture the error, if it's the "expected" error, then no error, if it's anything else, then it's a true error. Certainly not ideal, but I'm at a loss.

[Anonymous]

If the mover only moves files that match a pattern, can you PUT them with a temp name (that doesn't match), and then rename them after transmission?

[cmills]

Good question. Currently I don't have change permissions in their FTP folder, but I'll have that changed and try the renaming idea.
Still would like to see someone say they've seen this before. It's baffling that I've come across it with 3 entities in the past few months but cannot find a single resource on the internets.