☰

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

tag-icon • tag-icon filesystems stat
Linuxカーネルにはまだファイル作成日を取得するためのインターフェースがありませんか？

長い間、Linuxは一般的に使用されているファイルシステムのどれもファイル生成日をサポートしていなかったので、ファイル生成日を気にしませんでした。ただし、今日一般的に使用されている2つのファイルシステム（NTFSとext4）は、ファイル作成日を記録します。

statBirth: -ただし、ext4が使用されていることがわかりますが、コマンドはまだext4ファイルシステムから出力されますdebugfs -R 'stat <inode_number>' /dev/file_device。

なぜそうなのか調べてみると、他の人もそうだったことがわかりました。最近送信されましたこれに関するバグレポートの場合、応答は次のリンクにリンクされています。アップストリームの問題単に「現在この情報[ファイル生成日]を得ることができるLinuxカーネルインタフェースはありません」と明示されています。私にとっては、明らかに注目する価値があるまだstat人々がこの情報を何年も表示してもらうように要求してきたので、これが起こりました（まだ明らかにサポートしていませんが、フィールドを出力します！stat期待Birthどおりに追加しましたか？）。

それでは、ファイル作成日を取得できるLinuxカーネルインタフェースはまだありませんか？これを実現する計画はありますか？

答え1

編集：良いニュースです。statx()マージされたので、バージョン4.11で利用可能です。

xstat() ジョブ (現在 statx()) は 2016 年に改訂されました。

今回はプロセスがさらに厳しくなりました（自転車の流れが少なく、後で追加される可能性があるため、議論の余地のある属性を削除することに同意します）。残念ながら、正確なインターフェースについて依然として異議を申し立てている人がおり、更新された参考資料を見たことがありません。

答え2

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

私が知っている限り（申し訳ありませんが、リンク、メモリ、インターネット検索が多すぎるため、ここに参照用にリストするほど凝集力はありません。）下線システムが生成時間属性をサポートしていなかったためではなく、できませんでした。役に立つ機能の1つであることに同意しません。

バラより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フィールドを処理する方法とフィールドの命名についても誰も同意できなかったという事実です。提起された質問熱い議論。

答え3

誕生時間はext4だけでなく、いくつかのLinuxベースのファイルシステムにありました。

Linuxカーネルバージョン4.11から起動（2017年4月）新しい内容があります。statx()システムコールそれを検索します。ただし、対応するラッパー関数はまだGNU libcに追加されていません（2018-06-26ベース）。2019年編集これで2.28に追加され、GNUstatなどlsのツールはfindそれを使用するように更新されていません（2019-08-22 編集GNU / Linuxシステムstatのglibc 2.28以降はcoreutils 8.31以降をサポートしています。2021-01-04 編集GNUには8.32からcoreutilslsがあります--time=birth）

次のようにこれを実行できます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.ph。SYS_statxamd64アーキテクチャでは332です。または、次のことを試してください。

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

今日の誕生時間はほとんど役に立ちません。これはファイル内のデータの寿命ではありません（データがファイルに書き込まれました）。後ろに作成された場合）、ファイルがその名前のディレクトリに表示される場合も必ずしもそうではありません（別の名前で作成され、名前が変更またはリンクされている可能性があり、その間に内容や属性が何度も変更された可能性があります）。

1特別な場合としてext4の場合、ファイルシステムが128バイトのinodeサイズで作成された場合、生成時間フィールドは含まれません。

関連情報