Linux不能修改文件创建时间（btime/crtime），因内核无写入接口，touch仅能设置atime和mtime，ctime自动更新，btime只读且不可控。
touch 的行为，或者混淆了 Windows 的 creationtime 概念。Linux 没有等价的用户态 API，touch 根本不接受、也不处理 btime。
为什么 touch -d 或 touch -t 不影响创建时间
touch 只能触发内核对 atime 和 mtime 的写入，ctime 会随元数据变更自动更新；而 btime 字段在 ext4/XFS 中虽已存储，但内核未暴露写入接口。执行 touch -d "2020-01-01" file 后：
• stat -c "%y" file（mtime）会变
• stat -c "%x" file（atime）可能变（取决于挂载选项）
• stat -c "%w" file（btime）不变，且通常为空或显示当前时间（新建时才写入）
• stat -c "%z" file（ctime）必然变成操作时刻
stat 显示 Birth 时间 ≠ 支持写入
即使 stat -c "%w" file 输出一个非空时间，也只代表该文件创建时被记录过，不代表你能改它：
• ext4：需内核 ≥ 4.11 + 文件系统启用 metadata_csum 和 64bit 特性，否则 %w 恒为空
• XFS：需内核 ≥ 5.10 + 挂载时开启 bigtime，且 xfs_io -c 'btime' 仅限 root，行为不稳定、不保证持久
• debugfs 查到的 crtime 是只读快照，不是可编辑字段
• 所有声称“成功修改 btime”的工具（如某些 GUI 文件管理器或第三方软件），底层要么伪造输出、要么依赖未公开的调试接口，不可信
真正可控的时间戳只有 atime 和 mtime
日常能稳定操作的只有访问和修改时间，方案必须围绕这个前提设计：
• 把文件“看起来像”更早创建：删掉原文件，touch 新建，再用 touch -r ref_file new_file 复制 atime/mtime
• 批量重设日志文件的修改时间为今天零点：for f in *.log; do [ -f "$f" ] && touch -m -d "today 00:00" "$f"; done
• 仅同步参考文件的 mtime（不碰 atime）：touch -m -d "$(stat -c "%y" ref_file)" target_file
• 避免误用 touch -r ref_file -m target_file：它仍会把 ref_file 的 atime 也复制过去
试图硬改 btime 的风险远大于收益
用 debugfs -w 直接写 ext4 inode 或 patch 内核模块强行注入 btime：
• 极易破坏文件系统校验（如 ext4 的 metadata_csum）
• 导致 e2fsck 报错、文件丢失或只读挂载
• 不跨文件系统通用（XFS 下无效，btrfs 完全不支持）
• 无法通过 POSIX 接口验证，后续程序读取时可能返回 0 或随机值
• 在 CentOS Linux 7.9.2009 等旧系统上，连 stat -c "%w" 都不识别，更别说写入
mtime 实现。真正需要篡改 btime 的场景（比如取证模拟），应使用文件系统镜像级操作，而非单个文件时间戳调整。 
