Issue #9772 has been updated by Yui NARUSE.
Akira T. wrote:
ruby-core:62137 で Eric W. も尋ねていますが、なぜ POSIX で定義されている statvfs じゃなくて、statfs
なのか、というのは私も最初に疑問に思いました。理由を参照できる形で残しておくのは重要だと思うので、説明を書いていただけないでしょうか。
statfs では f_type の類がとれないからですね。[ruby-core:62150]
そして、その理由があったとしても、API としては statvfs という名前にして、
statfs が存在する環境ではより多くの情報がなぜか取得できるとした方がいいのではないかという気がします。
(理由がないのであれば、もちろん statvfs にすべきだと思います。)
うーん、ファイルシステムの情報であって特別VFSの情報ってわけでもないしなぁ、
と思いつつPythonさんを見るとos.statvfsなんですね。
Motohiro KOSAKI wrote:
ああ、statvfsにメンバ追加のほうが世の中で主流なのですね。じゃあ、わたしの主張は取り下げます
statfs は残しつつ、statvfsでは標準のメンバしか出さないLinux, FreeBSD, Darwin, OpenBSDと、
statvfs に寄せた上で独自拡張するプロプライエタリ(と、NetBSD)って読むのが正しいんじゃないですかね。
なお、NetBSDとOpenBSDでは動くようにした…はずです。
Feature #9772: IO#statfs and File::Statfs
- Author: Yui NARUSE
- Status: Assigned
- Priority: Normal
- Assignee: Yukihiro M.
- Category:
- Target version:
IO#statfs and File::Statfs を追加しませんか。
(テストで statfs.f_type が必要だったのでとりあえず追加してしまっていますが)
statfs(2) は Unix 系 OS
でそこそこ普及している、あるパスが属するファイルシステムについての情報を得るためのシステムコールです。
OS によって多少差がありますが、だいたい以下の様な情報が得られます。
struct statfs {
uint32_t f_type; /* type of filesystem */
uint64_t f_bsize; /* filesystem fragment size */
uint64_t f_blocks; /* total data blocks in filesystem
/
uint64_t f_bfree; / free blocks in filesystem /
int64_t f_bavail; / free blocks avail to
non-superuser /
uint64_t f_files; / total file nodes in filesystem
/
int64_t f_ffree; / free nodes avail to
non-superuser /
char f_fstypename[MFSNAMELEN]; / filesystem type name */
};
f_type の値が OS 依存だったり、Linux 以外だとそもそもどれがどの値かきちんと定義されていないとか
ツッコミどころの多い API ではあるのですが、他では得られない情報が得られます。
たとえば、以前から CRuby で使われている用途としては、あるファイルの乗っているファイルシステムが、
HFS+ かどうかがわかります。言い換えると、ファイル名が正規化されているかどうかがわかります。
ありがちな反論として、書き込めば正規化されるかわかるだろうというのがありえますが、
目当てのファイルと同じディレクトリに書き込めるとは限りません。
違うディレクトリだと別のファイルシステムがマウントされている可能性があります。
なお今回の用途は、SEEK_DATA/SEEK_HOLEができるか否かを、実際にやってみる以外の方法で知りたかった、というものです。
(Rubyのテストなのにやってみて調べるではテストにあまりならない)