ctime总是<= mtime吗？

Question

在Python中使用os.stat()时，我可以假设st_ctime总是小于或等于st_mtime吗？若否，原因为何？

代码将始终在Linux上运行，但如果OSes之间有区别，那将是一件很好的事情。

Answer 1

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

• 时区。比方说，如果您在UTC+4中创建了一个文件，然后在当前时区为UTC-8时对其进行了修改，并且操作系统在幕后并未对所有时间戳都使用UTC，则修改后的时间将小于创建时间。对于现代操作系统(Windows、OSX、BSD或Linux)来说，在这个case.
• Resetting中有mtime < ctime代表操作系统时间，这将是令人惊讶的。这可能会影响创建这种情况的修改时间。我想说，在这种情况下，假设文件系统驱动程序中没有适当的检查来通过系统调用来避免这种case.
• Modifying，那么在这种情况下，你更有可能拥有mtime < ctime而没有来自操作系统的抱怨。同样，文件系统驱动程序可能会进行相应的检查，以避免出现此类异常情况。

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

也是，st_ctime不一定是“创建时间”，而是“上次状态改变”(source)的时间。utime标记要更新的文件的ctime (source)，它的"utimbuf“类型的参数没有ctime的成员。因此，在操作系统和文件系统允许的情况下，ctime在技术上可以超过mtime。os.stat文档实际上提到了这一点：

与

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

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

Answer 2

请定义“小于”，你的意思是新的还是旧的？您不能假设ctime发生在mtime之前，但通常情况下，ctime与mtime相同，或者在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

完全可以通过编程方式设置这两个值。通过将时钟设置回创建文件之前，您也可以“自然”地执行此操作。

换句话说，是的。这将是不寻常的，但完全有可能。