Windows Task to PUT files onto FTP location issue

Hi all,

I'm currently using WINSCP to test an inbound and outbound file transfer in a testing environment. I'm using Windows Task Scheduler to do this. The server I'm working is using Windows Server 2003.

Below is the suffix I've placed onto the task, and I'm successfully able to retrieve files from the /deliverynotes location, and save them to the local directory defined.

FTP Get


Below is the entire string in the task

I have the following as my suffix for an FTP PUT command

FTP PUT

Below is the string in the task


I've attached the logs for the outbound PUT task. It is going through the files and recording it is moving them, but it is not. I've run this from cmdline using Winscp.com, and I can see there is 0B being marked against the files and a 0% status before it terminates.

Would greatly appreciate help. I did an original test on this in a W7 environment and all worked fine, but having problems trying to get my setup work in a server 2003 environment.

I do not see any problem in the log.

The output on the console says 0B because the files are indeed empty.

Can you add XML logging to the code and listing of the remote directory after the upload?

C:\PROGRA~1\WinSCP\WinSCP.exe /log=K:\DATA\FTP\Savage_and_Whitton\Logs\winscp_outbound.log /xmllog=K:\DATA\FTP\Savage_and_Whitton\Logs\winscp_outbound.xml /command "open sftp://applegreen:[Password]@217.37.98.165" "put K:\DATA\FTP\Savage_and_Whitton\SiteOrders /orders" "ls /orders" "exit"

And attach both the .log and the .xml

Can you also show logs from the Windows 7 for a comparison? (and with XML and the ls).

martin wrote:

I do not see any problem in the log.

Yeah I guess that is kind of the problem. Everything looks like its completing successfully, but no file movement is taking place.

The output on the console says 0B because the files are indeed empty.

Cool, woopsie on my part. I was adding text to some of the text files but left these blank. Nice spot!

Can you add XML logging to the code and listing of the remote directory after the upload?

C:\PROGRA~1\WinSCP\WinSCP.exe /log=K:\DATA\FTP\Savage_and_Whitton\Logs\winscp_outbound.log /xmllog=K:\DATA\FTP\Savage_and_Whitton\Logs\winscp_outbound.xml /command "open sftp://applegreen:[Password]@217.37.98.165" "put K:\DATA\FTP\Savage_and_Whitton\SiteOrders /orders" "ls /orders" "exit"

And attach both the .log and the .xml

Will do. I'll add that shortly and run through a cycle and post back the logs.

Can you also show logs from the Windows 7 for a comparison? (and with XML and the ls).

Will do

Outbound logs in both .log and .xml format.

So weird it reads to me like it is transferring the files successfully, but cannot see them on the FTP site.

Wondering if its maybe a permissions issue.

What exactly, do you do to "see them on the FTP site"?

Do you have the logs from Windows 7?

I have a Winscp UI open on another machine, where I'm looking at the FTP server itself.

So for the GET command, I can see files being retrieved from the FTP location, and being placed onto a location folder.
For the PUT command, I cannot see files being placed onto the FTP location.


I've looked into my W7 test I had, and realised that its probably not relevant. I had run these commands using a RaspberryPi as a FTP, to test the theory and commands. So while that worked, its not the FTP location I'll actually be using.

I've changed my W7 tasks to reflect the correct FTP location, and same issue is occurring. Logs for that attached.

OK, so I need to see the script log file for text with the ls command (the same as you have posted already). And a log file from the GUI, showing how you refresh the remote directory immediately after the scripted upload.

Attached are the GUI logs.
I've also provided a screenshot showing the "changed" date on the UI, showing right now. I ran the PUT task and saw the date change on the interface, but again no files showing.


Can you expand on the request below?

so I need to see the script log file for text with the ls command

Sorry, it should have been "test", not "text".