メッセージ
2011年11月06日の記事
2011/11/06(日)春Ｍ(SpringM)のタイムスタンプ仕様の確認
2011/11/06 11:11
春Ｍの「日付の変更」ダイアログで変更できるのは最終変更日時。
さて、FAT32とNTFSでは記録精度が違う。春Ｍは古いソフトなので、FATの仕様を引きずっている。まあ現在でもFATファイルシステムはUSBメモリなど随所にあり、他のファイルシステムでもNASやバックアップ・ファイルコピーツール等々で同様に発生する問題でもある。
[NTFS]
作成日時:100ナノ秒単位で記録
最終変更日時:100ナノ秒単位で記録
最終アクセス日時:100ナノ秒単位で記録(ただし、1時間以内の同種のアクセスは無視)
参考:NTFSの最終アクセス日時 - B-) の独り言
[FAT32]
作成日時:10ミリ秒単位で記録
最終変更日時:偶数秒単位で記録
最終アクセス日時:1日単位で記録
参考:File Allocation Table
記録時間がUTCかローカルかって違いもあるけど割愛。
で、春Ｍの場合、「日付の変更」ダイアログでは秒単位まで入力可だが、内部で偶数秒単位に丸めている。また、表示も偶数秒単位に丸められる。ただし、更新の場合と表示した場合でちょっと挙動が違う。
[更新した場合]
2011/11/06 09:54:26に更新→2011/11/06 09:54:26.0000000で記録
2011/11/06 09:54:27に更新→2011/11/06 09:54:26.0000000で記録
2011/11/06 09:54:28に更新→2011/11/06 09:54:28.0000000で記録
切り下げっぽい動きになる。
[表示した場合]
2011/11/06 09:54:26.0000000→2011/11/06 09:54:26
2011/11/06 09:54:26.0000001→2011/11/06 09:54:28
2011/11/06 09:54:26.9999999→2011/11/06 09:54:28
2011/11/06 09:54:27.0000000→2011/11/06 09:54:28
2011/11/06 09:54:27.9999999→2011/11/06 09:54:28
切り上げっぽい動きになる。
さらにややこしいことに、Windowsのファイルプロパティ(秒まで表示)では、
[ファイルのプロパティ(Win7Pro 64bitで確認)]
2011/11/06 09:54:26.0000000→2011/11/06 09:54:26
2011/11/06 09:54:26.0000001→2011/11/06 09:54:26
2011/11/06 09:54:26.9999999→2011/11/06 09:54:26
2011/11/06 09:54:27.0000000→2011/11/06 09:54:27
2011/11/06 09:54:27.9999999→2011/11/06 09:54:27
切り下げっぽい動きになる。
春Ｍの画面上のソートはナノ秒まで含めて正確に行われるようなので、ちょっと混乱した。
なお、ActiveRuby1.8.7のFile.mtime(秒まで取得可)の挙動とかも確認してみたけど、基本Windowsのプロパティ画面に出てくる値と同じだった。本当はどのAPIを使ってるかも調べるべきなのだが、とりあえず今回はここまで。
調査は
Restamper
とか使った。こっちが信用できないともう知らん。