[ruby-dev:38282] Re: big time

In article <[e-mail]>,
  Urabe Shyouhei <[e-mail]> writes:

> ここまでまとめて返答しますが、想定しているのはFileUtils.touchのような、
> File.utimeへのラッパーライブラリです。FileUtils.touchはFile.utimeが受け付けない
> ような引数は受け付けたくないわけです。ところが、田中さんのパッチを当てると
>
> /usr/lib/ruby/1.9.2/fileutils.rb:1033:in `utime': time out of system range
> (ArgumentError)
>         from /usr/lib/ruby/1.9.2/fileutils.rb:1033:in `block in touch'
>         from /usr/lib/ruby/1.9.2/fileutils.rb:1030:in `each'
>         from /usr/lib/ruby/1.9.2/fileutils.rb:1030:in `touch'
>         from -e:1
>
> などというエラーが出ますね?これでは知らない人が見ればFileUtilsにバグがあるよう
> に見えるわけです。FileUtilsの側としては、FileUtilsは悪くないわけですから、この
> ようなバックトレースを表示せずに、なるならもっと手前のところで例外になってほし
> い。つまり、この例で言えば
>
> -e:1:in `new': time out of range (ArgumentError)
> 	from -e:1
>
> とかそんな感じになってほしいわけです。

そうするとわからないのが、なぜ卜部さんがサブクラスを提案する
のか、ということです。

File.utime が Time を受け付けないようにしても、バックトレー
スには fileutils が依然として出てきますよね。

サブクラスは何を解決するんですか?

> それは私の理解とは違いますね。fstatが成功して意図した値が返ってくるなら、それは
> 更新に成功しています。その後の値が保証されないのは、たとえば他のユーザーが横か
> らtouchしたり、いくらでも弄ることは可能なことからも明かです。そもそもVFATじゃな
> くてもumountした時点で、ディスク抜いて他のマシンでmountして更新時刻弄ってるかも
> しれないじゃないですか。
> utimeはあくまで設定した瞬間以降の値は保証していないはずと思います。

他でいじっているものがあるかもしれないし、ないかもしれません。
それは外部の状況に依存します。

私がテストした状況では、私が全体について管理していて、そうい
う他からいじっていたものがなかったことは保証できます。

なお、unmount しなくても、しばらくすると 1970 から 1980 に変
化しているという現象も確認しました。

私がここでうまくいくと述べた意味は、意図した時刻が
atime/mtime としてファイルシステムに記録される、ということで
す。これはユーザの意図に近い想定だと思います。

中田さんのメールにもあるように、ファイルシステムが
1970-01-01 という日付を表現できないので、私が述べた意味でう
まくいくということはないでしょう。

> バグレポートが何回も何回も来ることを考えてください。
> ライブラリの作者は一人のことが多いですが、ユーザーは普通、一人より多いです。何
> 回却下しても同じバグが次々と別の人から報告されることはあります。「自分のせい
> じゃないバグ報告でモチベーションが削がれ」とは、そういう状況を指しています。

File.utime に関するものが増える以上に、Time 自身の制約に起因
するバグレポートが減ることを推測しています。

とりあえずふなばさんのモチベーションが削がれることは減るんじゃ
ないでしょうか。

>> File.utime が Time オブジェクトを受け付けなくなると、
>> いままで File.utime に Time を渡していたすべてのコードで問題
>> が起きます。
>> 
>> それに対して、File.utime が、time_t の範囲外の Time オブジェ
>> クトを受け付けないというのは、すべてよりは少ないコードでしか
>> 問題が起きないでしょう。
>
> この推測には私は賛成も反対もできません。
> 過去、Timeがtime_tの範囲を外れたことがないので、そのようなケースが多いか少ない
> かは予測不可能だと思います。
> 特にTime.nowが2038年に近づくとそのようなケースは増えるのではないかと個人的には
> 危惧しています。

上記の記述は、time_t の範囲内と範囲外を比べたものではありま
せん。

「すべて」すなわち「範囲内と範囲外を両方あわせたもの」と
範囲外の部分を比べたものです。

この比較で範囲外のほうが少ないのは自明でしょう。

>> 卜部さんが救いたいというのは後者に関する話ですが、それは前者
>> の問題よりは少ないでしょう。
>
> したがって定量的評価はこの部分にこそ欲しかったのですが。

File.utime が Time オブジェクトを受け付けないというのは
time_t の範囲内か範囲外かにかかわらず問題が起きます。

それに対して、File.utime が Time オブジェクトを受け付ければ、
問題が起こるのは範囲外のときだけです。

当然、後者のほうが少ないでしょう。

>> また、File.utime がなんらかの範囲外でうまく動かないという意
>> 味で、似た問題は 64bit time_t で NFSv3 とか GNU/Linux で
>> VFAT とか既にあるので、そこからの類推も可能です。ML の過去の
>> メールを検索しても範囲外の問題と明確にわかるものはありません
>> でした。これから類推すると問題は例外的な話におさまるでしょう。
>
> Rubyの場合、time_tの範囲外のTimeオブジェクトはこれまで生成できなかったので、ML
> を検索しても問題が報告されていないのは自明と思います。

ここで私が述べた「なんらかの範囲外」というのは time_t の範囲
を外れることではありません。ファイルシステムが表現できる範囲
を外れることです。これは現在でも問題が起こりうるものです。そ
して、どちらの範囲も指定できる時刻を制約するものであることか
ら類推が可能であろう、という主張です。
-- 
[田中 哲][たなか あきら][Tanaka Akira]