Description
As pointed out in this StackOverflow post, Windows' CreationTime is less similar to Unix' ctime concept than we previously assumed: on Windows, it does not necessarily change when a file is deleted and recreated again. Indeed, even when renaming a file and then renaming another file to the former's former name, the CreationTime won't change.
Instead, ChangeTime is what we're after. It changes when the file's metadata changes, such as its file name or its location.
This should also help the funny issue where editing a file using Excel might not change the LastWriteTime, and neither the CreationTime, but the ChangeTime.
Originally, we used CreationTime because ctime was interpreted to mean "create time".
Then, we could not change it because we used the FindFirstFile()/FindNextFile() functions in the FSCache, which have access to CreationTime but not to ChangeTime.
In the meantime, however, we use NtQueryDirectoryFile() instead (because it is actually faster), which does have access to ChangeTime.
The regular non-FSCache mingw_stat() uses GetFileInformationByHandle(), which does not have access to the ChangeTime. We might be able to remedy that by switching to GetFileAttributesExW(), GetFileInformationByHandleEx() or some other API function that does have access.
Note: we might want to use this opportunity to switch to using FILE_ID_FULL_DIR_INFORMATION in fscache_stat() to get the equivalent of inodes, and the equivalent nFileIndexHigh/nFileIndexLow in mingw_stat().