From ca10c06819aacc50d4423836ce51fc4486803789 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 12 Mar 2016 12:57:18 -0400 Subject: rename files containing : This is mostly to let the repo check out on windows w/o using cygwin's git. But, bash completion is also crap with : , so .. --- ...nt_12_e4d268f269cc1701736cc5a39719ac20._comment | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment (limited to 'doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment') diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment new file mode 100644 index 000000000..8d06ee857 --- /dev/null +++ b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment @@ -0,0 +1,23 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="108.236.230.124" + subject="comment 12" + date="2014-06-11T18:05:48Z" + content=""" +The resolution problem does not seems to affect Windows, at least not on NTFS. In my tests, the mtime is fully preserved across reboots there. + +However, any change to the timezone on Windows does manage to mess up all the timestamps. Presumably this same flawed approach is used for DST adjustments. + +Example from inode cache after a 1 hour time zone change, which forced git-annex add to re-checksum: + +
+--1 2221 1395843799
++-1 2221 1395847399
+
+ +Of course, not all time zones are 1 hour offset, so as a heuristic, treating timestamps +- 60*60*Int as the same, would be pretty bad. Instead, it would probably make sense, on windows, to normalize the timestamp, using the current time zone, to get to the UTC timestamp. (Of course on unix, a file's timestamp is always given in UTC.) + +Unfortunately, Data.Time.LocalTime.getCurrentTimeZone doesn't seem to really work on windows. It always returns UTC+1 in my tests. + +Anyway, I'm now looking at this as two separate problems, the Windows Time Zone Sucks problem and the FAT Metadata Sucks problem. They will probably have different solutions.. +"""]] -- cgit v1.2.3