Moving Files to Folder on Remove Server After FTP

Post any question you may have in regards to GoAnywhere Director and let our talented support staff and other users assist you.
4 posts Page 1 of 1

J Haskins

Posts: 5
Joined: Mon Apr 30, 2012 1:48 pm

Post by J Haskins » Thu Nov 07, 2013 2:19 pm
I have a project that gets customer POs via ftp off a remote server. After the current set of files has been gotten, they need to be moved to an archive folder on the remote server.

The 'get' works fine, but when I then try to move the files, I get permission denied errors. Below is what the ftp part of my project looks like:
Code: Select all
		<ftp resourceId="Spring Systems - live" version="1.0" logLevel="debug" disabled="false">
			<get label="Get Orders" destinationDir="${system.job.workspace}" type="binary" destinationFilesVariable="Orders" numFilesDownloadedVariable="Count">
				<fileset dir="knitrite-reports/PO_data/" />
			</get>
			<move destinationDir="knitrite-reports/PO_data/archive/">
				<fileset dir="knitrite-reports/PO_data/" />
			</move>
		</ftp>
I've confirmed that I have permission to do this on the remove system, so that shouldn't be the problem.

When I look at the job log, it appears that the project is trying to delete the files, even though there isn't a delete instruction in the project.
"
I'm sure the problem is some stupid little thing that I've overlooked. But I can't figure it out.

Any suggestions would be appreciated.

Thanks!

Support_Rick

Support Specialist
Posts: 590
Joined: Tue Jul 17, 2012 2:12 pm
Location: Phoenix, AZ

Post by Support_Rick » Thu Nov 07, 2013 2:58 pm
J...

Try something like this:
Code: Select all
		<ftp label="Connect to Server" resourceId="Spring Systems - live" version="1.0" logLevel="debug" disabled="false">
			<get label="Get Orders" destinationDir="${system.job.workspace}" type="binary" destinationFilesVariable="locOrders" numFilesDownloadedVariable="Count" processedSourceFilesVariable="rmtOrders">
				<fileset dir="knitrite-reports/PO_data/" />
			</get>
			<move label="Archive PO&apos;s" sourceFilesVariable="${rmtOrders}" destinationDir="knitrite-reports/PO_data/archive/" />
		</ftp>
The way you have it coded currently, if .. (by chance) .. someone places a PO into the folder after you're already pulling the original PO's, you will archive the "new" PO before it gets processed.

Using the above technique allows you to identify (on the remote server) the exact files that you have retrieved, then using that Variable (in this case ${rmtOrders}) will automatically point you to the files you have retrieved and only archive those files. Any "new" POs will be left for the next processing.

Let me know if you have any questions or if this works for you.
Rick Elliott
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696

J Haskins

Posts: 5
Joined: Mon Apr 30, 2012 1:48 pm

Post by J Haskins » Thu Nov 07, 2013 3:29 pm
Rick,

Thanks for the suggestion, it makes a lot of sense.

Unfortunately, that didn't solve the problem.

The job log shows that the project is getting the files. It even looks like the inital move is going to be ok. But then it seems to be trying to delete the file from the directory it is trying to move it to. At that point I get a 'permission denied' error. See below:
INFO Moving '/knitrite/knitrite-reports/PO_data/PO_data_20130607_125150.csv' to '/knitrite/knitrite-reports/PO_data/archive/PO_data_20130607_125150.csv'
DEBUG COMMAND: DELE /knitrite/knitrite-reports/PO_data/archive/PO_data_20130607_125150.csv
DEBUG REPLY: 550 deletion failed
DEBUG COMMAND: RNFR /knitrite/knitrite-reports/PO_data/PO_data_20130607_125150.csv
DEBUG REPLY: 550 permission denied
I don't understand when the deletion is coming from. The archive directory is empty.

Any suggestions?

Support_Rick

Support Specialist
Posts: 590
Joined: Tue Jul 17, 2012 2:12 pm
Location: Phoenix, AZ

Post by Support_Rick » Thu Nov 07, 2013 4:28 pm
The FTP move action uses the rename commands, which consists of two: RNFR (rename from) followed by RNTO (rename to).

The delete you see is GoAnywhere trying to delete the 'target/destination' file, just to ensure it doesn't exist before renaming to that file. In most cases, we expect this to fail because it usually won't exist. The reply for the delete says it failed, not permission denied, so this is probably because the target doesn't exist (as expected).

In the logs provided, the server is clearly rejecting the RNFR (rename from) from command with 'Permission denied'. So although you may have permission, it doesn't look like you have enough to rename and need to contact the server administrator to provide that support.
Rick Elliott
Lead Solutions Consultant
(402) 944.4242
(800) 949-4696
4 posts Page 1 of 1