Aman Thind wrote:
Hi Wiggins

The appearance of ABOR is extremely random.
I've successfully uploaded huge files with this script without any issues.
So this is possibly being generated by the server I'm uploading my files
to...but WHY ?



I still think it is being generated at the client end, see below for why (I think this, not why it is happening). Also notice the "arrows" >>> vs. <<<....


I used the debug flag for the ftp and here's an excerpt of the output :

Net::FTP=GLOB(0x1f32e14)<<< 200 PORT command successful.
Net::FTP=GLOB(0x1f32e14)>>> APPE
/Development/XPress/LatestBuild/6.0/1341/Instal
ler/Mac/QuarkXPress 6.0 Installer.hqx

Each command you send (the client) to the server begins with a command string, such as the 'APPE' in the above line.


Net::FTP=GLOB(0x1f32e14)<<< 150 Opening BINARY mode data connection for
/Develop
ment/XPress/LatestBuild/6.0/1341/Installer/Mac/QuarkXPress 6.0
Installer.hqx.

Then the server responds with a line that should start with a 3 digit result code, such as the '150' in the above line that tells the client that either the previous command was successful or failed and for what reason. So in the below...


Net::FTP=GLOB(0x1f32e14)>>> =ABOR

That makes ABOR a command from the client to the server.


Net::FTP=GLOB(0x1f32e14)<<< 426 Connection closed; transfer aborted.

This is a status line.


Net::FTP=GLOB(0x1f32e14)<<< 226 ABOR command successful.

And then your last command returns successful, which theoretically explains why your 'Reconnect' is never called, because append is returning true because the last command was successful. Now the question becomes why does the 'append' method send an =ABOR command and then return true.


Net::FTP=GLOB(0x1f14100)<<< 220 productserver Microsoft FTP Service (Version
5.0).

And I have no idea why this line would be sent.



The output stood at the "150 Opening BINARY..." line till the upload was being made and then suddenly the =ABOR appeared and the transfer stopped !


Does the command sometimes succeed and sometimes fail to the same server on the same machine over the same net connection? Or is this a server dpeendent thing, or something else? Two ideas on this front come to mind, first firewalling and passive vs. active transfers, and secondly M$ FTP service is notorious for doing this kind of crap....


How can I augment my following line of code :

$ftp->append(\*FH,$remotefile)||Reconnect();

so that Reconnect is called when =ABOR springs up to make my life
miserable...


Hard to say, you could check the output of the FTP session (yikes), you could test the size of the files on the two locations (yikes again). Maybe someone else here can provide more insight into what Net::FTP might be doing. I took a look at the source for it but couldn't track down where the =ABOR could be coming from.


Fear I haven't been all that much help, don't where else to look...

http://danconia.org



-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 10:14 PM To: Aman Thind; [EMAIL PROTECTED] Subject: RE: ABOR message using Net::FTP



------------------------------------------------
On Fri, 13 Jun 2003 21:18:32 +0530, Aman Thind <[EMAIL PROTECTED]> wrote:


Hi

My ftp script sometimes stops working after throwing an ABOR message :(

I invoke the ftp as :

$ftp->append(\*FH,$remotefile)||Reconnect();

But when ABOR comes, reconnect is not called.
However if i take my machine out of the network while doing the ftp, it
invokes Reconnect() as it should.

Any remedies please...

b.t.w. the msg that comes is ABOR and not ABORT incase you're thinking i'm
bad at spelling... :)



From what the RFC says this is generally sent by the client to tell the
server to stop doing whatever it is that it is doing, are you sure this is
coming from the server side or is it being generated in your script (or
Net::FTP) somehow? Presumably the ABOR is working, which is then replying
with a successful message that is preventing the reconnect.

You can set a Debug flag in your Net::FTP constructor that will print
verbose information that may help fix the issue.

http://danconia.org




--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to