Your best friend for file transfer.

Fetch application logoFetch

Connection issues at a particular FTP site (8 posts)

  • Started 1 year ago by Jim Brandt
  • Latest reply 1 year ago from Jim Matthews
  • Jim Brandt Member

    Jim,

    I’m having an issue with logging on to a specific FTP site and need to run this by you.

    All of this is using Applescript. I’m simplifying this as much as possible while trying to show the issue I’m having.

    set FTP_Site to “ftp://” & UserName & ":" & UserPass & "@" & HostAddress

    where UserName = the username
    UserPass = the password
    HostAddress = the site address (string, not numeric)
    ThePort = 21

    Method 1:

    set tw to make new transfer window at beginning with properties {url:FTP_Site}
    tell tw to set ConnectionStatus to status

    Method 2:

    make new transfer window with properties {hostname:HostAddr, username:UserName, password:UserPass, port:ThePort, authentication:cleartext password}
    tell transfer window 1 to set ConnectionStatus to status

    For this particular site, UserName and UserPass, Method 1 fails every time, while Method 2 succeeds everytime.

    The failure of Method 1 is while getting the list of files at the remote location, according to the transcript window. Its hard to capture it because I’m closing Fetch and reopening it on failure and the window resets when you do that. The script is attached to a watch folder also, so I’m having to jump through hoops to debug this. I’m inclined to add more error trapping and write the resulting error messages to a log file (something I need to do anyways), but I use this script every day as part of my job and recently we changed the location of the FTP site and now it’s failing more often than it succeeds in connecting.

    Question 1: is there a difference using method 1 vrs method 2?

    Question 2: since method 2 is specifying the authentication while method 1 does not, is authentication something that “carries over” from one login to the next?

    Question 3: what exactly does the “at beginning” in method 1 do? (this was code you gave me in an answer to a question I asked over a year ago. I put it in without paying attention to it’s purpose).

    Jim Brandt

    Posted 1 year ago #

  • Jim Matthews Administrator

    Hi,

    Question 1: I don't see any reason why one of those methods would work and the other one not work. They should be equivalent as long as the script is the only Fetch "user" at the time (if you or another script opened a transfer window between the first and second lines of Method 2, "transfer window 1" wouldn't be the right window).

    Question 2: The authentication method is implicit in the FTP_Site URL you construct for Method 1

    Question 3: The "make" verb is built into AppleScript, and is supposed to take a parameter that tells the application where to make the new object. The "at the beginning" fills that role, but doesn't really make a difference (I don't think there's a way to tell Fetch to make a new window anywhere but in front).

    I hope this helps. I sympathize with the difficulty of debugging folder action scripts!

    Jim Matthews
    Fetch Softworks

    Posted 1 year ago #

  • Jim Brandt Member

    OK. Here's the Transcript Window text for one of these failures:

    Fetch 5.7.5 (5H1476) Intel (Web Store) running on Mac OS X 10.10.5 (14F1713) Intel English
    StuffIt Engine 0x820, StuffIt SDK Version 10.1.1b1
    Partial serial FETCH55001-4BNU-MZ4P T
    Connecting to ftp.spothub.com port 21 (Mac OS X firewall is allowing connections) (4/14/16, 10:57 AM)
    Connected to 52.9.27.151 port 21 (4/14/16, 10:57 AM)
    220-Welcome to CrushFTP!
    220 CrushFTP Server Ready!
    USER WTXF
    331 Username OK. Need password.
    PASS
    230 Password OK. Connected. logged in
    SYST
    215 UNIX Type: L8
    PWD
    257 "/" PWD command successful.
    PWD
    257 "/" PWD command successful.
    PWD
    257 "/" PWD command successful.
    TYPE A
    200 Command ok : ASCII type selected.
    PASV
    get_reply():con_conn->Getline() returns 1,54
    ftp_list: 2,-30014 (state == GETTING_LIST)
    QUIT
    send_cmd():con_conn->Putline() returns 1,54

    It's connecting and quitting almost immediately when running under the script.

    If I log in manually, I can get to the site. This is driving me nuts, because a lot of other things the script does for me are not getting done because of this failure (I send a lot of files that are causing this to fail). BTW, this was all working until about a week ago. And, no, I didn't change the script (well, not the FTP login and send part, anyways :>) ).

    Posted 1 year ago #

  • Jim Matthews Administrator

    That's odd -- the connection is dropping when Fetch starts to get a file list. I don't see anything suspicious there from the Fetch side.

    You might try catching the error in your script, and trying again, to see if it's just a temporary problem. Let me know if you want advise on writing that code.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 1 year ago #

  • Jim Brandt Member

    No, I don't need advice on that code. I've already got it trapped. Twice. The first time I display a message that the site failed to connect, I quit Fetch, reopen it and try again. On the second failure, I display a message and move on to the next upload.

    This whole process is driven by dropping plist files in a watch folder that define the FTP credentials and the source of the files for upload and email addresses for notification. The FTP is part of the script attached to the watch folder.

    This has me baffled, as it worked mostly flawlessly up until a couple of weeks ago.

    BTW, the -30014 error is the same error I'm seeing on the trapped error section.

    One more question: is there a way to tell Fetch how long to wait for a connection (in a script)? I have a couple of stations that are very slow in responding and I sometimes get disconnected just as the file list is coming through (the list is very large and takes a long time to generate on their end).

    OK, back to the drawing board.

    Thanks,

    Jim

    Posted 1 year ago #

  • Jim Brandt Member

    No, I don't need advice on that code. I've already got it trapped. Twice. The first time I display a message that the site failed to connect, I quit Fetch, reopen it and try again. On the second failure, I display a message and move on to the next upload.

    This whole process is driven by dropping plist files in a watch folder that define the FTP credentials and the source of the files for upload and email addresses for notification. The FTP is part of the script attached to the watch folder.

    This has me baffled, as it worked mostly flawlessly up until a couple of weeks ago.

    BTW, the -30014 error is the same error I'm seeing on the trapped error section.

    One more question: is there a way to tell Fetch how long to wait for a connection (in a script)? I have a couple of stations that are very slow in responding and I sometimes get disconnected just as the file list is coming through (the list is very large and takes a long time to generate on their end).

    OK, back to the drawing board.

    Thanks,

    Jim

    Posted 1 year ago #

  • Jim Matthews Administrator

    That -30014 error means that the server dropped the connection while Fetch was waiting for the reply to a command. If you have access to the server logs you might find information to help understand the failures on that end.

    There isn't a way to tell Fetch to wait longer for a connection. I believe that it waits 75 seconds.

    Thanks,

    Jim Matthews
    Fetch Softworks

    Posted 1 year ago #

  • Jim Brandt Member

    I found the problem.

    The "Use passive mode transfers" preference was checked. Apparently this site doesn't like passive transfers.

    Problem solved by unchecking preference.

    Sorry to be of trouble.

    Jim

    Posted 1 year ago #

  • Jim Matthews Administrator

    Well done! Glad you found the problem.

    Jim Matthews
    Fetch Softworks

    Posted 1 year ago #

Reply

  • Or nickname, if you prefer.
  • This will be kept confidential.
  • This is to ensure that you’re a person, not a spambot.