もちろんそういうユーティリティでいじった場合を除く。
作成日時(CreationTime)が正しくなくなる場合
- 別ボリュームへ移動した場合。その移動の日時に設定される。KB299648
- 同名のファイルを削除直後に再作成した場合など。いわゆるトンネリング。その直前に削除したファイルの持っていた作成日時に設定される。ドロナワ式対策の大好きなMicrosoftらしいとんでもない仕様だ。KB172190
最終更新日時(LastWriteTime)が正しくなくなる場合
- Win32のCreateFileMapping(), MapViewOfFile()や、そのラッパーである.NET Framework 4.0のSystem.IO.MemoryMappedFilesを使って、メモリマップトファイルとして書き込みをした場合。最終更新日時は更新されない。調べた限りではこの仕様はドキュメント化されておらず、別に原因のある可能性もなくはないが、検証用プログラムを作って試した限りではそうなる(追記: 英語版MSDNの最新版には記述があった)。SQL Serverのバックアップ処理がこれをやっているらしく、バックアップファイルは、そのサイズが最後に拡張された日時が最終更新日時として設定されているようだ。バックアップ処理にどの程度の時間がかかったかを調べる際に実に紛らわしい。
なお、posixのmmap()には、マップされたメモリ領域への書き込み以降(かつmsync()が呼ばれたならその呼び出し以前)の時刻でst_mtimeが更新されるという記述がある。posixサブシステム(SUA)からmmap()を呼ぶとどうなるか興味があるが未検証。