しらいです。
んー、先の mail はさとうさんに対するツッコミのつもりだった
んですが、そうは読めなかったでしょうか。誤解を招いてしまって
すみません。
In Message-Id <20080812213938.b6fdee59.touchan@xxxxx>
KAWASUMI Junji <touchan@xxxxx>さんwrites:
> 川澄です。
> > でも、「未対応」を示す数値は birthtime 実装環境では現れ得
> > ない数値でないと、区別がつかなくなるんじゃないかと思うんです
> > がどうでしょう？
> そうですね、単純に 0より大きかったら採用という風に思っていまし
> たが、浅かったです。
UTC を返してる st_birthtime の方はそれでも構わないと思いま
す。完璧じゃないにしろ、実用上特に問題ないでしょう。epoch に
遡って file を作成するニーズなんてまずありませんし。
> でもソースで確かめたわけでは無いですが、FreeBSD上で UFS1で作っ
> たファイルに対してbirthtimeがどうなるか実行してみたところ、
> エポック時間 1970/1/1 09:00:00 が返却されてきました。
> なので、何となく 0でいいんじゃないかと思いました。
なら st_birthtime だけを見ればいいんじゃないでしょうか。対
応環境でも 0 という値を取り得る st_birthtimensec は、対応可
否の判断基準に用いるべきではないと思います。
さとうさんの patch その 2 の方を見ると、nsec 値が 0 になっ
てしまうと st_birthtime の方が有効な値であっても「非対応」と
見なしてその値は使わないんですよね。
問題はこの可能性がどのくらいあるかですけど、epoch に遡って
file 作成という詐称無しにはあり得ない頻度と比べて 10^(-9) と
いう頻度は十分に大きいと思います。
毎秒 file 生成を続けて 30 年に 1 回ですか。PC が 30 台あれ
ば年 1 回の割合です。RTC の分解能を考えるともっと大きな確率
で nsec 値が 0 になり得るでしょう。
＃ 逆に RTC の特性で nsec 値は決して 0 にならないという保証
＃があればまだいいんですけど、それでも将来 RTC が高性能にな
＃ってしまうとそんな保証は無くなると思います。
> > > st_birthtimensec もあるかどうか調べて、両方 0 か両方 -1 なら
> > > 無視するのがいいのかなぁ。
> >
> > 10^(-9) の確率で nano second 値って 0 になるんじゃないかと
> > 思うんですが、UFS2 や FFS2 の実装のどこかにそれを回避する仕
> > 組みって用意されています？
> 個人的には、st_birthtimensecまで必要と思いませんが如何でしょう
> か。
さとうさんが言ってるのは、nsec 値を有効数値として使うとい
う意味ではなくて、nsec 値が無効な値を示していた際には、仮に
st_birthtime が有効範囲にあっても無視するという意味です。
nsec 値そのものは不要であるという点に関しては誰も異論ない
と思いますよ。
しらい たかし