web-dev-qa-db-ja.com

ファイルの作成日を取得するLinuxカーネルインターフェイスはまだありませんか?

Linuxは長い間、ファイル作成日を気にしていませんでした。これは、Linuxが一般的に使用するファイルシステムのどれもそれらをサポートしていないためです。ただし、現在、一般的に使用される2つのファイルシステム(NTFSとext4)はどちらもファイルの作成日を記録しています。

ただし、statコマンドは、ext4がBirth: -を使用してファイルの作成日を格納していることが確認できても、ext4ファイルシステムでdebugfs -R 'stat <inode_number>' /dev/file_deviceを出力します。

これがなぜなのかを調べたところ、誰か他の人が既に 最近提出した バグレポートであり、応答は 上流の問題 にリンクしているだけであることがわかりました。現在、その情報[ファイル作成日]を取得するLinuxカーネルインターフェイスはありません。人々がstatに何年もの間この情報を表示するように要求してきたので、これは明らかにまだの場合であることに私には注目に値します(そしてstatは、まだサポートしていないようですが、Birthフィールドを出力します!期待して追加しましたか?)

それでは、ファイルの作成日を取得するためのLinuxカーネルインターフェイスが現在存在しないというのは本当ですか?これを実装する計画はありますか?

21
Jez

編集:朗報、statx()がマージされたので、リリース4.11で利用可能になるはずです。


xstat()の作業、現在はstatx()が2016年に改訂されました。

今回のプロセスは少し厳しくなりました(バイクシェディングを減らし、論争の的となる属性は後でいつでも追加できるため、削除することに同意しました)。残念ながら、正確なインターフェースにはまだ反対意見があり、最近の参考文献は見ていません。

15
sourcejedi

一般的に使用されているファイルシステムはどれもサポートしていなかったため

私が知ることができること(リンク、メモリ、およびグーラゲの束、申し訳ありませんが、ここに参照としてリストするのに十分な凝集性はありません)から、それは下線を引いているシステムが作成時間属性をサポートしていなかったためではありませんでしたそれが便利な機能だったことに同意します。

http://www.pathname.com/fhs/pub/fhs-2.3.html を参照してください

POSIXは3つのタイムスタンプをレイアウトします。それらのどれも作成時間ではありません。

私が正しく覚えているなら、議論は次のようなものでした:

> Give me a use case where we can't already do that using what we already have.
< Some examples were submitted
> All of these are convoluted beyond usefulness. 
> Ok, Ok, *maybe* a couple of these don't suck. 
> Now how do you see handling file systems that don't track this?
< several ideas that were not the same. 
< Basically everyone had a special case that would work, but not 
< one that always works. Fight about fallbacks and other special handling. 
> Ok, lets table that for now. What should we call this field
< At least 6 different answers emerged.
> So, you want to break POSIX standards, 
> you can't really come up with a good reason why, 
> you can't come up with a good fall back, and 
> you can't even come up with a name. 
> Sounds like it's specific to the file system to me, and that 
> should be "extended data" accessible by tools and not as 
> a core stat in the Kernel.

今、これの多くは記憶といくつかの古いメーリングリストを読んでいます。私は議論の中心にも座りませんでした。組み込みLinuxシステム用のファットドライバーでのオフシュート作業のため、メーリングリストに参加していました。確かにもっと信頼できる情報源があるので、私がちょっと気にかけた何かの私の記憶よりも確かにそうです。

大事なことは、誰も良いユースケースを思いつくことができず、作成時間をサポートしていない他の40の一般的に使用されるファイルシステムのフィールドを処理する方法に誰も同意できないという事実の組み合わせであることを覚えています。そしてフィールドの名前を思いつくことさえ、大規模な議論に変わりました。

4
coteyr

誕生時間は、ext4だけでなく、いくつかのLinuxネイティブファイルシステムにあります。

Linuxカーネルのバージョン4.11以降 (2017年4月)、それを取得するための新しい statx()システムコール があります。ただし、対応するラッパー関数はまだGNU libcに追加されていません(2018-06-26現在。2019 edit2.28で追加されました)GNU statlsfindのようなツールはそれを使用するように更新されていません( 2019-08-22 editGNU stat(glibc 2.28以降のGNU/Linuxシステム) coreutils 8.31以降でサポート)

あなたはPerlでそれをすることができます:

Perl -MPOSIX -e '
  require "syscall.ph";
  $buf = "\0" x 0x100; # enough space for a struct statx
  for (@ARGV) {
    # hardcode: AT_FDCWD == -100
    #           AT_SYMLINK_NOFOLLOW = 0x100 (lstat()-like)
    #           STATX_BTIME = 0x800 for the mask
    #           80: offset of the btime in the struct
    syscall(&SYS_statx, -100, $_, 0x100, 0x800, $buf) == 0
      or die "$_: $!\n";
    ($t, $n) = unpack("x80QQ", $buf);
    $n = sprintf("%09d", $n);
    print strftime("%F %T.$n %z\n", localtime $t)
  }' -- "$file"

syscall.phSYS_statxがない場合は、ハードコードすることもできます。 AMD64アーキテクチャーでは332です。または試してください:

printf '#include <syscall.h>\n__NR_statx\n' | gcc -E -xc - | tail -n 1

今、その誕生時間はめったに役に立ちません。ファイル内のデータの古さ(データがファイルに書き込まれる後に作成された後)ではなく、ファイルがその名前でディレクトリに表示された時間(必ずしも別の名前で作成され、そこで名前が変更またはリンクされ、コンテンツまたは属性がその間に数回変更された可能性があります)。

3