Linux用stat命令查看文件创建时间(crtime)

许多 Linux 用户都曾遇到这样的困惑：使用 stat 命令查看文件创建时间时，结果要么为空，要么显示一个 -，甚至把修改时间（ctime）误当作创建时间输出。这并非操作方式有误，而是底层文件系统本身并未存储这一字段。

简单来说，stat 命令默认输出的 Birth 字段通常为空或显示 -。更令人困扰的是，某些场景下它会将 ctime（inode change time）伪装成创建时间。这一问题的根源在于 Linux 内核以及主流文件系统（如 ext4、XFS）本身就不保存 crtime（creation time）信息。

哪些文件系统真正支持 crtime？

能够通过 stat 正确返回 crtime 的文件系统非常有限。以下情况属于例外：

• btrfs：需启用 inode_cache，并在挂载时携带对应选项。较新内核默认已开启此功能，此时 stat 可以显示 Birth 字段。
• XFS：要求更为严格。内核版本需 5.10 及以上，文件系统格式必须为 v5（取决于格式化时的参数），且挂载时需启用 inode64 或使用默认配置。最可靠的验证方式是运行 xfs_info，检查输出中是否包含 feature: crtime。
• apfs（macOS 专属）和 NTFS（通过 ntfs-3g 挂载并开启 crtime 选项）在原生 Linux 环境下基本不具备参考价值。

执行 stat /path/to/file 后，如果看到的 Birth 字段为 - 或 —，基本可以确定当前文件系统不支持该字段。

为什么 Birth 字段经常不可信？

即使 stat 真的输出了一个时间，也未必可靠——它很可能并非真正的创建时间：

• ext4 文件系统从头到尾都不存储 crtime。但 RHEL 8+ 或 CentOS 8+ 等发行版为兼容 POSIX 工具链，让 stat 将 ctime（inode change time）填入 Birth 字段。这不是 Bug，而是刻意的设计。
• 旧版 coreutils（stat 所属的包）在缺乏 crtime 支持时会直接留空，新版本则悄悄 fallback 到 ctime，但文档中很少明确说明这一点。
• 在容器或 overlayfs 环境中，宿主机文件系统本身就不支持 crtime，上层调用 stat 也无法获得真实信息。

验证方法很简单：运行 stat -c "%z %w" /path，它会分别输出 ctime 和 Birth。如果两个值完全相同，则很可能属于伪造数据。

真想查文件诞生时间？别指望 stat

在标准 Linux 环境下，没有一种通用且可靠的方法能够获取文件的原始创建时间。如果确实需要，可以尝试以下几种途径，但各有利弊：

• 若使用 btrfs 并确认已启用 crtime，可通过 stat -c "%w" /file 直接读取 Birth 字段。但必须先用 lsattr /file 和 sudo debugfs -R "stat " /dev/sdXN 交叉验证——注意，在 ext4 中 debugfs 不会输出 crtime。
• 依赖日志：如果提前配置了 auditd 规则，例如 -a always,exit -F arch=b64 -S openat -F success=1 -k file_create，事后可使用 aureport -k file_create 查询。但前提是事先已经做好了准备。
• 依赖备份或版本控制系统：Git 的提交记录、rsync 的日志、restic 的快照（restic snapshots --json）等，往往比文件系统本身更加可信。它们记录的“创建时间”才是真正有意义的时间点。

最后需要明确的是，在多数生产环境中，“文件创建时间”本身就是一个语义模糊的概念。mv、cp、tar 解包，乃至编辑器另存为新文件，都可能导致创建时间被覆盖或重置。如果确有审计需求，应当从源头设计日志采集机制，而不是寄希望于 stat 能凭空变出魔术。