Re: How to COPY (not transfer) a file on a remote server using FTP

On 08-Dec-2011 16:59 , Dan wrote:

On Thu, Dec 8, 2011 at 6:09 PM, CRPence<CRPbottle@xxxxxxxxx> wrote:

<<SNIP>>
To determine what the server will accept, review output from the
request to: QUOTE HELP

QUOTE HELP returns a list of mostly 4-character commands, none of
which seem to help me accomplish what I'm trying to do. This exercise
reminds me of when we have FTP scripts on our PC to run commands on
the i:
QUOTE RCMD CALL PGMA PARM( SOMETHING )

So, I used FTP on my PC to open a connection on our i, and used
QUOTE HELP. Sure enough, there's RCMD in the list of commands. Then I
used QUOTE HELP RCMD and I see the syntax. I need that RCMD on the
Windows server!

So, it looks like I'm S.O.L. as far as running a Windows command like
XCOPY on the server. I might give a shout to our Server Ops to see
if there's a setting they can change on the server that allows an
FTP GET to work on an open file. This *was* the working behavior up
until a few months ago.

That was my recollection from old versions of Windows Server 200# and past discussions looking for the same RCMD feature that FTP on IBM i provides. But if there is or could be made available an active REXEC daemon on the Windows Server, then RUNRMTCMD should enable a means to issue the XCOPY; e.g. RUNRMTCMD issued via the client request [FTP subcommand] SYSCMD, or in a CLP wrapper for the FTP processing. That text should provide good search criteria for finding past discussions on this list.

Of course any other communications method for which the server is both "listening" and can effect the proper response [not necessarily a command dynamically generated by the client] could suffice. For example, even a request to PUT a specific named file within the same FTP session, for which the creation of that file by name triggers [some service on] the server to perform the desired XCOPY as a response.

My perception is... The wrong question [i.e. the subject] is being
asked.

<<SNIP>>

John correctly responded to this.

If there is such trust in the application actually being complete, regardless that the file remains open, then why not have the application make the copy after "completing" the work. Or better, just have the application close the file, since if the application is truly done updating the file, there is no need to keep the file open.?

Why implement a work-around that must rely on the assumption that the open and unavailable file is no longer being updated? Admittedly, so it seems, that assumption was apparently already being made, just that no error was being manifest. At least changing the application to close the file prevents making another copy on the server, and the data getting copied yet again, to the FTP client.

Regards, Chuck