scttnlsn/dandelion

`getresp': 500 TOR not understood (Net::FTPPermError)

sassman opened this issue · 5 comments

Seems that with some FTP server versions the TOR command is unknown. Some error handling and fallback logic would be nice to let the deployment not break.

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:326:in `getresp': 500 TOR not understood (Net::FTPPermError)
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:351:in `block in sendcmd'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:349:in `sendcmd'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:428:in `transfercmd'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:543:in `block (2 levels) in storbinary'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:199:in `with_binary'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:542:in `block in storbinary'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/monitor.rb:211:in `mon_synchronize'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:541:in `storbinary'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/net/ftp.rb:690:in `putbinaryfile'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/adapter/ftp.rb:31:in `block in write'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/utils.rb:9:in `temp'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/adapter/ftp.rb:29:in `write'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/deployer.rb:49:in `deploy_change!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/deployer.rb:13:in `block in deploy_changeset!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/changeset.rb:28:in `block in each'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/diff.rb:58:in `block in each'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/diff.rb:57:in `each'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/diff.rb:57:in `each'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/changeset.rb:20:in `each'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/deployer.rb:9:in `deploy_changeset!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/command/deploy.rb:55:in `deploy_changeset!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/command/deploy.rb:30:in `execute!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/lib/dandelion/cli.rb:73:in `execute!'
    from /Library/Ruby/Gems/2.0.0/gems/dandelion-0.4.14/bin/dandelion:8:in `<top (required)>'
    from /usr/bin/dandelion:23:in `load'
    from /usr/bin/dandelion:23:in `<main>'

What sort of fallback logic are you thinking of?

If the ftp command TOR leads to that issue, then I would catch the error and give STOR a try. I'm not so sure if the use of TOR in general is not a bug in the FTP client. I was not able to find the TOR command in the RFC for ftp protocol.

http://www.nsftools.com/tips/RawFTP.htm#STOR
http://www.w3.org/Protocols/rfc959/4_FileTransfer.html

the ftp adapter is using the ftp.putbinaryfile, so I would write a wrapper function and implement the behaviour to fallback to the ftp raw command STOR there.

It looks like the Ruby FTP client is correctly using "STOR": https://github.com/ruby/ruby/blob/7393bf6a5cfff63683f36535e293caaa0d4c5be0/lib/net/ftp.rb#L694 Am I misunderstanding the issue?

It seems that I missunderstood the issue. It happens randomly, and seems that the server connection was interrupted. That lead to the issue.
However passive mode enabled seems to do the trick and no more errors like this appears.