ctime总是<= mtime吗？

Question

在Python中使用os.stat()时,我可以假设st_ctime总是小于或等于st_mtime吗？如果没有,为什么不呢？

代码将始终在Linux上运行,但如果操作系统之间存在差异,那么这将是一件好事.

Answer 1

你把这件事搞错了！在 Linux（或 Mac，或任何其他 Unix 系统）上，ctime通常总是晚于mtime，而不是早于 。与 Windows 不同，其中ctime是文件创建日期，mtime是文件修改日期，在 Unix 中它们都是修改日期，区别在于：

• mtime每当文件内容发生变化时都会更新
• ctime每当文件属性发生变化（包括其属性）时都会更新mtime

stat该实用程序（至少是其某些变体）的手册页将它们分别称为“上次数据修改时间”和“上次状态更改时间”。

因此，每当mtime更新时，ctime也会更新。据我所知，您可以获得mtime比以下更大的唯一机制ctime：

• 使用或系统调用或使用它们的实用程序手动将 设定mtime为将来utimeutimestouch -d
• 以绕过 Linux 文件系统 API 的方式写入磁盘，或者实际上完全绕过文件系统，例如：
  • 从 Windows 写入磁盘
  • 打开磁盘的设备文件并写入
  • 使用激光、磁铁、声波螺丝刀或类似工具翻转磁盘上的位

既然您已经在 Python 环境中提出了问题，那么让我们制作一个简单的 Python 工具来输出给定文件的mtime和来帮助我们演示这一点。我们将在脚本中ctime使用方便的os.path.getctime和API，但使用调用结果的和属性将给出完全相同的结果：os.path.getctimest_ctimest_mtimestat

#!/usr/bin/python
import os
import sys

target_filename = sys.argv[1]

mtime = os.path.getmtime(target_filename)
ctime = os.path.getctime(target_filename)

print('mtime: %f ctime: %f' % (mtime, ctime))

我们可以将其另存为pystat.py，使其可执行，并在我们的 Unix shell 中进行实验：

#!/usr/bin/python
import os
import sys

target_filename = sys.argv[1]

mtime = os.path.getmtime(target_filename)
ctime = os.path.getctime(target_filename)

print('mtime: %f ctime: %f' % (mtime, ctime))

Answer 2

请定义“小于”，您是指新的还是旧的？您不能假定ctime发生在mtime之前，但是通常ctime与mtime相同或相同。

Unix上的ctime不是“创建时间”，而是“更改时间”。文件内容更改时，mtime会更新，但是文件元数据更改时，ctime也将更新（这意味着mtime也将在更新时更新），因此ctime在mtime之后是完全正常的。这是一个例子：

user@ubuntu:~$ touch test
user@ubuntu:~$ chmod 600 test
user@ubuntu:~$ stat test
  File: «test»
  Size: 0          Blocks: 0          IO Block: 4096   regular empty file
Device: 700h/1792d Inode: 222375      Links: 1
Access: (0600/-rw-------)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-01-03 12:35:15.945973569 +0100
Modify: 2011-01-03 12:35:15.945973569 +0100
Change: 2011-01-03 12:35:24.024998291 +0100

另外，我相信在Windows上，ctime字段实际上确实意味着“创建时间”，并且这是Windows与Unix之间的操作系统差异。我已经在网上阅读了有关此内容的内容，但我会让您对此进行自己的研究。

Answer 3

在某些情况下，这种假设可能被证明是无效的（并且很大程度上取决于操作系统的实现）：

• 时区。如果您以 UTC+4 创建一个文件，然后在当前时区为 UTC-8 时对其进行修改，并且操作系统在幕后的所有时间戳均不使用 UTC，则修改时间会更少比创建时间。在这种情况下，现代操作系统（Windows、OSX、BSD 或 Linux 之一）的 mtime < ctime 会令人惊讶。
• 重置操作系统时间。这可能会影响创建这种情况的修改时间。我想说，在这种情况下，假设文件系统驱动程序中没有进行检查来避免这种情况，那么您更有可能拥有 mtime < ctime 而不会受到操作系统的投诉。
• 通过系统调用修改时间。同样，文件系统驱动程序可能会进行检查以避免此类异常情况。

这两者都是可重现的：您最好的选择是采用您计划针对和测试此行为的各种操作系统。我所能提供的只是猜测。

另外， st_ctime 不一定是“创建时间”，而是“最后一次状态更改”的时间（来源）。utime标记ctime要更新的文件（源），其类型为“utimbuf”的参数没有成员ctime。因此，如果操作系统和文件系统允许，那么从技术上讲，ctime 可以超过 mtime。该os.stat文档实际上提到了这一点：

平台依赖；Unix 上最近元数据更改的时间，或 Windows 上的创建时间

虽然 Python 隐藏了很多 C 方面的东西，os.stat而且它的朋友们都建立在相同的基础 C 系统调用之上，所以它们的规范是寻找更多信息的好地方。