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

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

　LWE に出掛けていて反応が遅れました。会場から読むだけは読ん
でいたのですが。

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

> 先に書きました AIX や solaris での対処方法は、
> 変数の型やら関数名を 64 bit 対応のものへの強制的に
> 置換するものでした。

　long が何 bits なのか、また long long があるのか、といった
環境依存の問題に起因するので、一意な解はなかなか出て来ないと
思います。
　long は一般に 32bits 以上が保証されていますが、64bit OS で
は当たり前のように 64bits 幅あります。こういう環境では、素の
ままの FDclone で 2GB 越 file を扱える筈です。
　long long は C99 で採用されましたが POSIX には含まれていな
いため、実装されているか否かをいちいち調べて廻る必要がありま
す。結構 version 依存がありそうですので、OS で決め打ちしづら
いのが難点ですね。


> 最初から off_t が 8 byte のものはないかと見渡すと、
> FreeBSD が見つかりました。

　2GB 越の file を扱えるのに off_t が 32bits しかない環境は、
厳密には環境側の不備と言えるような気がします。
　POSIX では file size を表す st_size 要素の型は off_t と定
められており、この範囲内で表せないといけません。off64_t を用
いる stat64() のような拡張関数は POSIX では規定されていませ
ん。
　なので、FreeBSD など 4.4BSD 系の実装の方が正しいんじゃない
かと思っています。そういう OS 側の事情をアプリに押しつける方
がおかしいのではないかと。


> が、ファイルサイズ欄は ? でした。

　これは ascnumeric() が long で受けているからですね。この箇
所を long long にすれば「?」ではなく「999999999」になってく
れると思います。
　しかし、long long は環境依存が激しいので、恒久的な対処とし
ては、long 二つで受けて 32bits 計算の範囲内で処理するといっ
た工夫が必要になるんでしょうね。
　Linux の llseek() はそういう工夫で 2GB の壁を逃げている実
装なので、portability はありません。


> ただ挙動から見るに、サイズ順でソートすると一番小さいほうへ
> 表示されているので、 st_size でソートしていないのではないかと
> 思われます。

　これも long で比較しているためです。qsort() の比較関数の返
り値は int なので、差を取って返すのではなく大小関係を -1,0,1
に変換して返す必要があると思います。


> # HP-UX は 2G 以上の空きのあるファイルシステムが無く、
> # ファイル置き場である NAS が 2G 以上のファイルを作成できない
> # ものなので試していません。

　そもそも 2GB を越えられない filesystem って結構ありますよ。
昔の設計を引きずっていると、file size はなかなか上限を変えに
くいと思います。

　結論としては、
	・stat(2) に 32bits 制限のある環境は対象外。
	・stat(2) で取得可能ならば ascnumeric() は修正可。
といったところでしょうか。

                                               しらい たかし