パスワードを忘れた？ アカウント作成
Close
15234 story

WinSCP 4.0 beta で ftp サポート 18

ストーリー by yoosee
ftp-over-ssl-あたりは使われてるんでしょうかね 部門より

tab 曰く、

ssh を利用して ftp ライクな機能を実現する sftp のクライアント WinSCP(for MS-Windows)だが、WinSCP News にて WinSCP 4.0 beta のリリースがアナウンスされている。 それによると、新しいバージョンでは sftp や scp のみならず ftpの機能もサポートするようになるらしい。
ちなみに元々 ftp クライアントだった filezilla でも sftp が利用できるようになっているが、やはり ftp はまだまだ主流ということだろうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

WinSCP 4.0 beta で ftp サポート More

  • 4.0更新履歴 [winscp.net]によると、FileZillaベースのコードを元にftpアクセスしているようですね。
    sftp/scp対応のエンジンとしてPuTTYベースコードを使っていることといい、エンジンコア部分をよそからもらってくるのが好きなようです。
    それならそうで、各エンジンをDLLに分離してしまえばいいのに。
    --
    # rm -rf ./.
  • FFFTPとWinSCPの二つを利用してるのが何となく不便だと思っていたときに、EmFTPがSFTPも対応とのことで使ってたのですがFTPの方でうまく動作しないことが多発し(試用時試したFTPサーバでは問題なく動作してました)、結局FFFTPを手放せずにいたのでこれで統一できるといいなと思います。

    EmFTPのFTP問題は基礎の所らしいので直すには実質作り直しっぽいですね。
    WinSCPも同じようなミスをしなければいいのですが…
    --
    天琉陳(Teruching)
    • 意外とExplorerライクなFTPクライアントってうまく動かないことありますね(大量ファイル操作時など）。
      僕はFTP Voyager [ftpvoyager.jp]を愛用しています（有償の製品）。
      WinSCPも併用していますので、こちらに統一できたらいいですね。
      ただ、WinSCPは日本語ファイルの扱いに難があるかなあ。フォルダ名が日本語だと複数ファイルアップロード時におかしいのはうちだけでしょうか（ver.3.7.6)。
      シェア
      親コメント
    • EmFTPのFTP問題は基礎の所らしいので直すには実質作り直しっぽいですね。
      WinSCPも同じようなミスをしなければいいのですが…
      FFFTPは修正BSDライセンスでソースコードが公開されているので、うまいことノウハウを再利用してもらえるといいんですね。
      互換性命なアプリは、コード書き始める前に枯れた老舗ソフトのコードを一旦読んで罠に関する知識とかバッドノウハウとかを仕入れておくと、それだけで随分楽になりますから。

  • ftpは引退が必要なの？ (スコア:1)

    by tokushima (155) on 2007年04月24日 0時24分 (#1147155)
    > やはり ftp はまだまだ主流ということだろうか。

    ネットに公開するためのデータをアップロードするときとか、
    公開されているものをダウンロードするときとか、
    クローズドネットワーク内でのファイル転送とか、
    ftpで十分ならftp使えばよいと思うので、いつまでも主流だと
    思うのですが、ftpって何かダメなことあるんでしたっけ？
    --
    It's not who is right, it's who is left.
    • メタデータの取り扱いとでも言いますか、
      要はファイルリスティングはフリーフォーマットで良いので
      人間に優しいかもしれないけど機械にあまりやさしくないのが。
    • >ネットに公開するためのデータをアップロードするときとか、
      パスワードが平文で流れる。もちろんデータも。

      >公開されているものをダウンロードするときとか、
      httpで代替可能ですよね。

      >クローズドネットワーク内でのファイル転送とか、
      ファイルサーバ立てたほうが利便性は高いと思います。

      >ftpで十分ならftp使えばよいと思うので、いつまでも主流だと
      >思うのですが、ftpって何かダメなことあるんでしたっけ？
      もちろんメリットデメリットを考えた上でftpで十分な人はftpを使えばいいと思います。telnetで十分な人はtelnetを使えばいい。ftpを今後一切禁止するというわけではないから。ただ、パスワードが平文という点だけをとっても、一般大衆に第一候補として使わせるには十分でないと思います。
      • #1147376のACです。本筋とは関係ありませんが、

        >>公開されているものをダウンロードするときとか、
        >httpで代替可能ですよね。

        顧客にでかいファイルを渡すのに専用のウェブページを作ってそこからダウンロードしてもらっているんですが、あるとき「httpだと遅いのでftpでアクセスできるようにしてください」と言われたことがあります。なんか、そんな常識がまかり通っている世界もあるそうです。
        • >あるとき「httpだと遅いのでftpでアクセスできるようにしてください」と言われたことがあります。
          >なんか、そんな常識がまかり通っている世界もあるそうです。

          rikenのサーバからrpm落とす時も
          httpよりftpの方が速い。

          っていう実体験から、経験則でそう思ってたのですが。

          ちがうの？

          • Re:ftpは引退が必要なの？ (スコア:1, 参考になる)

            by Anonymous Coward on 2007年04月24日 15時14分 (#1147486)
            おっと、そういう実例がありましたか。

            ファイル転送処理自体はread()/write()を繰り返すだけですので、プロトコルによって大きな差が出るとは思えません。実装によって多少の差は出るかもしれませんが、ボトルネックはインターネット網であることが一般的ですので、そこで吸収されてしまうでしょう。

            ちなみにftpとhttpでどれくらいの速度差が出るのでしょうか。私の手元の環境で実験してみましたが、有意と思える差は出ませんでした。

            $ wget http://ftp.riken.go.jp/pub/fedora/core/6/i386/iso/FC-6-i386-rescuecd.iso [riken.go.jp]
            --14:56:51-- http://ftp.riken.go.jp/pub/fedora/core/6/i386/iso/FC-6-i386-rescuecd.iso [riken.go.jp]
                                  => `FC-6-i386-rescuecd.iso'
            Resolving ftp.riken.go.jp... 134.160.38.1
            Connecting to ftp.riken.go.jp[134.160.38.1]:80... connected.
            HTTP request sent, awaiting response... 200 OK
            Length: 89,618,432 [text/plain]

            100%[====================================>] 89,618,432 590.50K/s ETA 00:00

            14:59:20 (588.90 KB/s) - `FC-6-i386-rescuecd.iso' saved [89618432/89618432]

            $ wget ftp://ftp.riken.go.jp/pub/fedora/core/6/i386/iso/FC-6-i386-rescuecd.iso [riken.go.jp]
            --14:59:26-- ftp://ftp.riken.go.jp/pub/fedora/core/6/i386/iso/FC-6-i386-rescuecd.iso [riken.go.jp]
                                  => `FC-6-i386-rescuecd.iso.1'
            Resolving ftp.riken.go.jp... 134.160.38.1
            Connecting to ftp.riken.go.jp[134.160.38.1]:21... connected.
            Logging in as anonymous ... Logged in!
            ==> SYST ... done. ==> PWD ... done.
            ==> TYPE I ... done. ==> CWD /pub/fedora/core/6/i386/iso ... done.
            ==> PASV ... done. ==> RETR FC-6-i386-rescuecd.iso ... done.
            Length: 89,618,432 (unauthoritative)

            100%[====================================>] 89,618,432 590.46K/s ETA 00:00

            15:01:56 (587.32 KB/s) - `FC-6-i386-rescuecd.iso.1' saved [89618432]

            プロトコル以外の可能性として、
            ・ftpとhttpで別サーバになっていて、ftp側のリソースが空いていた。
            ・ftpとhttpで途中経路に違いがあった。
            ・どこかでhttpだけに帯域制限が掛かっていた。
            などもあるかもしれません。

            もちろんそういった事情もかんがみて自分の環境ではhttpとftpではftpを選択するというのはありなのですが、一般においてプロトコル自体に速度的な差はないと思います。

            とここまで書いて思いましたが、上記はある程度の大きなファイルを転送する場合に当てはまる話です。小さなファイルを大量に取得する場合は、転送が始まるまでのやりとりにhttpとftpで違いがありますので、有意な速度差が出る可能性はあります。rpmを取得するというのを単独のパッケージのことと思いましたが、インストール時などで多量のrpmを一度に取得するなどでしたらあり得るでしょう。
            シェア
            親コメント
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚