[FDclone-users:00200] Re: 巨大ファイルの扱い

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <03May28.175348jst.119055@inetgw.lightwell.co.jp>
        SHIOTA Shoichi <Shoichi.Shiota@lightwell.co.jp>さんwrites:
> 潮田です。

> AIX 4.2 上では AIX 4.1 とまったく同じ定義を使用することは、
> コンパイラーの設定ファイルで分かるので、この version を
> 使用しているユーザーに泣いてもらえれば・・・

　そういう訳にもいかないでしょう。やはり stat64() は無理があ
りそうですね。同様に open64() とか lseek64() とか使わなくて
はならない手間を考えると、余り現実的ではなかったかも知れませ
ん。


> HP-UX だけ -O が無いのですが、これはこの OS では -O ですら
> 危ないのでしょうか。

　HP-UX は license の関係で -O が未 support の cc がついてく
ることがあるそうです。-O は performance にのみ影響するものな
ので、弱者側に合わせるという方針の下 -O 無しにしています。


> あと、 HP-UX や Solaris も２種類の define は排他ってことは
> 無いでしょうか。

　AIX の場合 _LARGE_FILE_API が pre define されている環境が
あるようなので敢えて -U で undef しています。HP-UX や Solaris
でもそういう状況があるようなら明示的に undef しますが。
　色々調べた中には unistd.h の中で define されているという話
も載っているので、そんなところで定義されたら undef しようが
ありませんけど。


> > 　Linux 以外は 32bit 環境しか無いんでしたっけ？
> 多分ご存知で反語的に使用されているとは思いますが、 Linux 以外の
> ３種の OS すべてに 64 bit 環境もあります。

　そんな厭味な書き方はしませんよ。あったように記憶しているけ
ど記憶が不確かなので聞いてみただけです。


> この確認のために管理者にはじめて確認したのですが、うちの
>  HP-UX や Solaris は 64bit 環境のはずだそうです。
> 確認方法（コマンド）をしらないが、最低限 install されている
> 商用のソフト(CA 製の監視ソフト)は 64bit モジュールで動いている
> とのこと。
> FD(にかぎりませんが) が 32bit で作成されているのは、単に
> コンパイルラーが default で 32bit モジュールを作成しているから
> みたいです。

　ということは、EXTENDEDCCOPT に然るべき記述をすれば、HP-UX
や Solaris 環境でも 64bit 環境を用意出来るということでしょう
か？
　もし可能なら、上記の検証を HP-UX や Solaris に対しても実行
してみて貰えないでしょうか。本当に _FILE_OFFSET_BITS が無害
か否かは全然検証出来ていませんので。


> > 　もし Linux(Alpha) 環境があるんでしたら、上記の対処が Alpha
> > 版に対して特に支障をもたらさないかどうか、検証してみて頂けな
> > いでしょうか。
> 2G over のサイズを持つファイルの名前が表示されて、
> サイズ順でソート可能なことは確認しました。

　では、上記の対処で少なくとも Linux 環境なら 32/64bit 共に
支障なしということで宜しいですね？


> のソースで "-O -D_FILE_OFFSET_BITS=64" のある or なしの結果を
> みてみましたが変化ありませんでした。
> 
> # int[4], long[8], void *[8], size_t[8], off_t[8]　となります。

　多分標準で off_t が 64bits で、この識別子は off_t を 64bits
にする以外の効果はないために、元々 off_t = 64bits な環境では
何も効果をもたらさないということなんでしょうね。


> # 便乗   64bit 環境では
> # 実害はないと思いますが、custom.c で struct _envtable の def を
> # int へキャストしているところはワーニングになります。
> # char * > int ですので。

　これは元々 char * 型の構造体要素に int 値を入れてあるもの
を取り出しているだけなので、warning を無視して問題ありません。
　逆に sizeof(char *) < sizeof(int) の場合であっても、そもそ
も代入されているのは即値でせいぜい 256 未満の数値ですので、
桁溢れは起こしません。
　本来ならばこういうケースでは union を使うのが正しい実装な
んでしょうけど、変数名だとか要素名だとかを不必要に長くすると
可視性を落としてしまうので cast で逃げています。
　勿論、実害が発覚すれば書換えますけど。


> # もしかして samba-2.2.8a-ja-1.0 の方でも同じようなことを...

　あっちは porting と bug fix だけ担当しているのでそんなにや
やこしい話は出て来ません。portability だって autoconf 頼りで
すし。

　因みに Samba での LFS 対策は、configure 時に _LARGE_FILES
等の識別子を -D しておいた上で stat64() 等の有無を検知し、あ
れば「64」のついた方を使うようにしています。
　Samba も FDclone 同様、全ての system call に対して wrapper
を噛ませる実装なので、stat() <-> stat64() のような使い分けを
行なう必要のある source は一個だけで済みます。

                                               しらい たかし