Is ctime always <= mtime?

Please define "less than", do you mean newer or older? You can't assume that ctime happened before mtime, but normally ctime is the same as, or after, mtime.

ctime on unix is not "create time", but "change time". mtime is updated when a file's contents are changed, but ctime is updated when file metadata is changed (which means it's updated when mtime is updated too), so it's perfectly normal for ctime to be after mtime. Here's an example:

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

Also, I believe that on Windows, the ctime field actually does mean "create time", and that this is an os difference between Windows and Unix. I've read something about this online, but I'll let you do your own research on this.

It's entirely possible to set both values programmatically. You might also be able to have this happen "naturally" by setting the clock back to before the file was created.

In other words, yes. It would be unusual but is entirely possible.

There are some situations in which this assumption could prove invalid (and would depend very much on the OS implementation):

• Timezones. If you create a file in, say, UTC+4, and then modify it when the current timezone is UTC-8, and the operating system doesn't use UTC for all timestamps behind-the-scenes, the modified time will be less than the created time. It would be surprising for a modern operating system (Windows, OSX, one of the BSDs or Linux) to have mtime < ctime in this case.
• Resetting the OS time. This could affect the modified time to create this situation. I would say it would be much more likely that you would have mtime < ctime without complaint from the OS in this case, assuming there aren't checks in place in the filesystem driver to avoid this case.
• Modifying the times through system calls. Again, the filesystem driver may have checks in place to avoid unusual situations such as this.

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.

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:

platform dependent; time of most recent metadata change on Unix, or the time of creation on Windows

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.