From: Tomoyuki Chikanaga <chikanag@...>
Date: 2009-11-20T09:44:15+09:00
Subject: [ruby-dev:39736] Re: Net::FTP で upload   	の resume   	ができない

近永と申します。

検証ありがとうございます。
補足させて頂きます。

> そもそもから行くと、RFC では REST の後に APPE は使えないように見えます。
 先日のパッチではアップロードの再開時には REST を送信しないように
しました(transfercmd の第二引数を指定しないと REST が送信されない
ようになっていました)。

> また、このパッチは REST は関係なく、APPE でクライアント側の続きを
> サーバ側の末尾に追加すればいいだろう思想だと思われるのですが、
> RFC 的な立場から言えば、FTP サーバがファイルシステムに格納する際に
> 変換等を行っていると、必ずしもうまくいかないケースがあるはずです。
 たとえば ascii 転送で改行が変換されている場合などでしょうか？
一応、元々 REST で再開を試みるのは binary の時だけになっていました。

 REST での再開は RFC959 ではブロックモード/圧縮モードでのみ利用できる
ようです。ストリームモードの場合にファイルオフセットで再開位置を指定
するのは RFC3659 で定義された拡張だと思います。
 斜め読みですが、SIZE で取得した位置から再開(追加)することになって
いますので、上記の指摘は REST+STOR を利用するか APPE を利用するかに
関わらない問題ではないでしょうか。
 前回の転送が ascii 転送されていたり、そもそもサーバに存在するファイル
が転送しようとしているファイルの転送途中のものではない、というときには
追加してはいけませんが、それは Net::FTP を利用する側で判断するしかない
かと思います。

> 端的に言えばこの現象に関しては vsftpd 側が悪いような気がしています。
vsftpd に問題があるのは確かにそうだと思います。
FEAT コマンドの応答の中に "REST STREAM" を含んでいるので、
ストリームモードの REST+STOR が動作することが期待されるのに
ちゃんと動作してくれていませんから。

蛇足ですが参考に先日調査した FTP クライアントの動作をまとめておきます。
  FileZilla
    FEAT の結果を信頼してREST+STOR するか APPE するかを分岐。
    従って vsftp に対しては多分アップロード再開時には誤動作すると
    思います(動作は未確認)。
  ncftp
    全面的に REST+STOR から APPE に変更(ChangeLog より)
  FFFtp
    ソースは未確認ですが、「表示」->「処理内容をビューワで表示」から
    コマンドをみると APPE を利用しているようでした。

以上、よろしくお願いします。

NARUSE, Yui さんは書きました:
> 成瀬です。
> 
> Shugo Maeda wrote:
>> 2009年11月18日12:31 Tomoyuki Chikanaga <chikanag@nippon-control-system.co.jp>:
>>>  Net::FTP#resume= を使用してファイルのアップロードの
>>> 再開を可能にしようとしてみたところ、転送結果のファイルが
>>> 追加で転送した部分だけになってしまう現象に遭遇しました。
>>>  使用していた ftp サーバは vsftp (@RedHat Enterprise Linux)
>>> というものです。
>> (snip)
>>>  アップロードの resume は REST+STOR で実現されていますが、
>>> APPE を使用すれば期待したように再開できました。
>>> パッチを添付します。
>> ありがとうございます。先ほどcommitしました。
> 
> そもそもから行くと、RFC では REST の後に APPE は使えないように見えます。
> 
> また、このパッチは REST は関係なく、APPE でクライアント側の続きを
> サーバ側の末尾に追加すればいいだろう思想だと思われるのですが、
> RFC 的な立場から言えば、FTP サーバがファイルシステムに格納する際に
> 変換等を行っていると、必ずしもうまくいかないケースがあるはずです。
> 
> 端的に言えばこの現象に関しては vsftpd 側が悪いような気がしています。
>