FTP Mirror (Automise 4) Misleading error mnessage


(Mr Rimmer) #1

Had a problem with the FTP Mirror action today, whereby it would attempt to download remote files and write them to a network share.  After a while at the downloading stage, it returns with error 426, implying that there is a problem with the remote server.

This is the log:
CRC is not supported by this FTP Server.
Skipped Calculation of Server Time Skew
Generating Remote File List…
Listing Files in [/]
Listing Files in [//COWATCH03600]

Generated File Lists in [8592 milliseconds]
Evaluating Local Differences…
Evaluating Differences in [39173 milliseconds]
Downloading Files…
FTP Mirror failed with reply error [Transfer failed
] and response code [426].

Reply errors are typically caused by the server responsing to a request incorrectly.


For whatever reason, the problem appeared to be with the local share.  Filezilla also shows strange behaviour whereby the first access to the share takes over a minute to return.
The workaround I found is to write a text file locally just before running the mirror op.

So, three improvements:
1. Show the actual error rather than 426, which will give more guidance about what is going on.
2. Logging of the FTP commands and responses, much like FTP Connect does.
3. Fix spelling mistake in the last line of the log :wink:

Thanks!


(Jason Smith) #2

Hi Mr Rimmer,

Thank you for reporting what your seeing in the FTP mirror action. I will address your points as you have numbered them for clarity.

1. The 426 error is the error that has been reported by the client/server interaction. If writing to the target location generates an error, or becomes unresponsive the connection is terminated. This is usually due to a server timeout. The only indication of file writing taking longer than the server expected is the server having already terminated the connection.

2. The mirror action allows for logging a great deal about the communication and its progress. In the progress logging tab you can turn on “Log FTP Commands” to the behaviour you desire.

3. Thank you for picking up this spelling mistake. It will be corrected in the next release.


(Mr Rimmer) #3

Hi Jason,

I’m not sure the 426 is being generated by the (remote) server, as our supplier could find no evidence of connection problems during the transfer.  Is there a possibility that this is being used as a default value for the error number?
As for the loggin options, I’m using 4.0.0.855 and cannot see any “log FTP commands” on the any of the tabs.  Is this a v5 thing?


On a slightly different subject, is it possible to control the overwrite behaviour programmatically?

Thanks,

Arnold


(Jason Smith) #4

Hi Mr Rimmer,

The new logging options are part of Automise 5. I suggest loading your script up in Automise 5, it can live with Automise 4 and it will not overwrite your current Automise 4 project. This will help in diagnosing the connection issue as it will tell us what command is failing. The 426 is being reported by the client because of actions the server has taken to drop the connection. Your supplier will most likely see a timeout error on their side.

On your other point about programmatically controlling overwrites, there a few options available however no scripting is available for this.


(Mr Rimmer) #5

HI Jason,

Further developments here.  It seems to be a combination of issues to do with the local store (a QNAP box) and the remote FTP site both having glitches.  Using Filezilla, the file will download with a few retries.  Here is the log as it is at the moment (has been running for a few hours):
Status:    Starting download of /COWATCH03625/PSCEXT.ZIP
Command:    PASV
Response:    227 Entering Passive Mode (213,123,35,143,232,7).
Command:    RETR PSCEXT.ZIP
Response:    150 Downloading in BINARY file PSCEXT.ZIP (594022176)
Response:    426 Transfer failed
Error:    File transfer failed after transferring 23,754,518 bytes in 834 seconds
Status:    Starting download of /COWATCH03625/PSCEXT.ZIP
Command:    PASV
Response:    227 Entering Passive Mode (213,123,35,143,236,44).
Command:    REST 23754518
Response:    350 Restart from 23754518
Command:    RETR PSCEXT.ZIP
Response:    150 Downloading in BINARY file PSCEXT.ZIP (594022176)
Response:    426 Transfer failed
Error:    File transfer failed after transferring 196,225,931 bytes in 8065 seconds
Status:    Starting download of /COWATCH03625/PSCEXT.ZIP
Command:    PASV
Response:    227 Entering Passive Mode (213,123,35,143,225,139).
Command:    REST 219980449
Response:    350 Restart from 219980449
Command:    RETR PSCEXT.ZIP
Response:    150 Downloading in BINARY file PSCEXT.ZIP (594022176)
Response:    426 Transfer failed
Error:    File transfer failed after transferring 103,867,044 bytes in 2070 seconds
Status:    Starting download of /COWATCH03625/PSCEXT.ZIP

So I suppose the next question is, can the FTP Mirror operation support restarting a file that has partially downloaded after receiving a 426, as is shown above?

Thanks,

Arnold


(Jason Smith) #6

Hi Mr Rimmer,

In FinalBuilder 8 the FTP Mirror action has a retry tab. This allows setting of retrying an upload/download on any error that is received. It will even reconnect if the connection is dropped.


(Mr Rimmer) #7

Which is nice for people running Finabuilder!  Any chance this code can be ported to Automise?


(Jason Smith) #8

Great news! It already has been ported to Automise. Its available in the current release. 

http://downloads.automise.com/downloads/automise/500/AT500_723.exe