[#39606] [Feature:trunk] Dir instance methods for relative path — Nobuyoshi Nakada <nobu@...>

なかだです。

15 messages 2009/11/02
[#39607] Re: [Feature:trunk] Dir instance methods for relative path — Yukihiro Matsumoto <matz@...> 2009/11/02

まつもと ゆきひろです

[#39611] Re: [Feature:trunk] Dir instance methods for relative path — KOSAKI Motohiro <kosaki.motohiro@...> 2009/11/02

kosakiです

[#39660] [Bug:trunk] Enumerator.new {|y| y << 1 << 2 << 3 } — Yusuke ENDOH <mame@...>

遠藤です。

14 messages 2009/11/11
[#39661] Re: [Bug:trunk] Enumerator.new {|y| y << 1 << 2 << 3 } — Tanaka Akira <akr@...> 2009/11/11

In article <e0b1e5700911110537u2aacf835pc0aea13d89a92cef@mail.gmail.com>,

[#39685] [Feature #2366] private constant — Yusuke Endoh <redmine@...>

Feature #2366: private constant

23 messages 2009/11/14
[#39689] [Feature #2366] private constant — Yusuke Endoh <redmine@...> 2009/11/14

チケット #2366 が更新されました。 (by Yusuke Endoh)

[#40207] Re: [Feature #2366] private constant — Yusuke ENDOH <mame@...> 2010/01/28

遠藤です。

[#40239] Re: [Feature #2366] private constant — Masatoshi SEKI <m_seki@...> 2010/01/29

=1B$B31$H$$$$$^$9!#=1B(B

[#40243] Re: [Feature #2366] private constant — Yusuke ENDOH <mame@...> 2010/01/29

遠藤です。

[#40246] Re: [Feature #2366] private constant — Masatoshi SEKI <m_seki@...> 2010/01/29

=1B$B31$H$$$$$^$9!#=1B(B

[#40247] Re: [Feature #2366] private constant — "NARUSE, Yui" <naruse@...> 2010/01/29

成瀬です。

[#39720] hidden objectって? — keiju@... (Keiju ISHITSUKA)

けいじゅ@いしつかです.

15 messages 2009/11/18
[#39721] Re: hidden objectって? — Yukihiro Matsumoto <matz@...> 2009/11/18

まつもと ゆきひろです

[#39726] Re: hidden objectって? — keiju@... (石塚圭樹) 2009/11/19

けいじゅ@いしつかです.

[#39727] Re: hidden objectって? — Yukihiro Matsumoto <matz@...> 2009/11/19

まつもと ゆきひろです

[#39730] Re: hidden objectって? — keiju@... (石塚圭樹) 2009/11/19

けいじゅ@いしつかです.

[#39735] [Bug:trunk] r25230 causes SEGV arround Marshal — "NARUSE, Yui" <naruse@...> 2009/11/19

以下のコミット以降、後述の現象が発生するそうです。

[#39755] RbConfig.rubybin — Tanaka Akira <akr@...>

ruby コマンドのパス名を返す RbConfig.rubybin というメソッド

18 messages 2009/11/23
[#39756] Re: RbConfig.rubybin — Kouhei Sutou <kou@...> 2009/11/23

須藤です。

[#39814] Re: RbConfig.rubybin — Tanaka Akira <akr@...> 2009/11/30

In article <20091123.123808.1122146273169400964.kou@cozmixng.org>,

[#39815] Re: RbConfig.rubybin — KOSAKI Motohiro <kosaki.motohiro@...> 2009/11/30

> In article <20091123.123808.1122146273169400964.kou@cozmixng.org>,

[#39796] バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — keiju@... (Keiju ISHITSUKA)

けいじゅ@いしつかです.

14 messages 2009/11/27
[#39800] Re: バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — Yukihiro Matsumoto <matz@...> 2009/11/27

まつもと ゆきひろです

[#39803] Re: バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — keiju@... (石塚圭樹) 2009/11/27

けいじゅ@いしつかです.

[#39805] Re: バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — Yukihiro Matsumoto <matz@...> 2009/11/28

まつもと ゆきひろです

[#39806] Re: バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — keiju@... (石塚圭樹) 2009/11/28

けいじゅ@いしつかです.

[#39807] Re: バグ? ブロック引数で to_ary が呼ばれる必要のない場面で呼ばれる — Yukihiro Matsumoto <matz@...> 2009/11/28

まつもと ゆきひろです

[ruby-dev:39736] Re: Net::FTP で upload の resume ができない

From: Tomoyuki Chikanaga <chikanag@...>
Date: 2009-11-20 00:44:15 UTC
List: ruby-dev #39736
近永と申します。

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

> そもそもから行くと、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 側が悪いような気がしています。
> 


In This Thread