summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar http://joeyh.name/ <http://joeyh.name/@web>2014-06-11 18:05:48 +0000
committerGravatar admin <admin@branchable.com>2014-06-11 18:05:48 +0000
commitbbc655a7403c7003ffc8303454c3451af428025e (patch)
treef56ebe3586c27418e32a88480098081a2e3a285f
parent0cb0df0ad044911799909a73a3bd4dee7a54156d (diff)
Added a comment
-rw-r--r--doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment23
1 files changed, 23 insertions, 0 deletions
diff --git a/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment b/doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment
new file mode 100644
index 000000000..8d06ee857
--- /dev/null
+++ b/doc/bugs/FAT:_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:
+
+<pre>
+--1 2221 1395843799
++-1 2221 1395847399
+</pre>
+
+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..
+"""]]