在Python中使用 os.stat()时，可以我假设st_ctime总是小于或等于st_mtime?如果没有，为什么不呢?
When using os.stat() in Python, can I assume that st_ctime is always less then or equal to st_mtime? If not, why not?
该代码将始终在Linux上运行，但是如果操作系统之间存在差异，那么请知道.
The code will always run on Linux, but if there is a difference between OSes, that would be good to know.
推荐答案在某些情况下，此假设可能被证明是无效的(并且在很大程度上取决于OS的实现):
There are some situations in which this assumption could prove invalid (and would depend very much on the OS implementation):
- 时区.如果您在UTC + 4中创建文件，然后在当前时区为UTC-8，并且操作系统未在幕后使用所有时间戳的情况下对其进行修改，则修改后的时间会更少超过创建的时间.对于现代操作系统(Windows，OSX，BSD之一或Linux)具有mtime<在这种情况下为ctime.
- 重置操作系统时间.这可能会影响创建这种情况的修改时间.我要说的是，您的mtime<在这种情况下，ctime不会受到操作系统的投诉，假设文件系统驱动程序中没有检查以避免这种情况.
- 通过系统调用修改时间.同样，文件系统驱动程序可能已进行检查，以避免发生诸如此类的异常情况.
这两种方法都是可重现的:最好的选择是采用计划针对此行为的各种操作系统.我所能提供的只是猜测.
Both of these are reproducable: your best bet is to take a variety of operating systems that you plan on targeting and testing this behaviour. All I can provide is speculation.
也，st_ctime不一定是创建的时间"，而是上一次状态更改"的时间(源). utime标记要更新的文件的ctime(源)，并且其类型为"utimbuf"的参数没有ctime的成员.因此，如果操作系统和文件系统允许，则ctime在技术上有可能超过mtime. os.stat文档实际上提到了这一点:
Also, st_ctime is not necessarily the "created time", but rather the time of the "last status change" (source). utime marks the ctime of the file to be updated (source) and it's parameter of type "utimbuf" has no member for ctime. So it is technically possible for ctime to be a time past mtime if the operating system and filesystem permit it. The os.stat documentation actually mentions this:
取决于平台；最多的时间 Unix上最近的元数据更改，或者 在Windows上创建的时间
platform dependent; time of most recent metadata change on Unix, or the time of creation on Windows
虽然Python隐藏了很多C方面的内容，但os.stat和朋友都基于相同的基本C系统调用构建，因此它们的规范是寻找更多信息的好地方.
Whilst Python hides a lot of the C side of things, os.stat and friends are all built upon the same base C system calls so the specification for them is a great place to look for more information.
更多推荐
ctime总是< = mtime吗?
发布评论