blob: c213aa0a92d28a65c7b31d77a8110b29bacb9cf9 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 2"
date="2014-06-11T19:51:15Z"
content="""
Note that multiple time zone changes complicate this. I think that means that the delta can't be simply applied when comparing inode caches. Instead, probably it needs to be applied when generating inode caches.
A scenario:
1. Time zone is at +1h when the inode sential is written.
2. Time zone changes to +2h
3. File F is added (with a current timestamp of T)
4. Time zone changes to +5h
I am a little confused by which way windows moves the timestamps when the time zone changes. Let's assume I might get the sign wrong.
Let F's timestamp after step 4, F4 = T+-3h.
Let the delta after step 4, D4 = +-4h
And, let the delta after step 2, D2 = +-1h
If step 3 writes the current timestamp to the inode cache, then the cache still has T in it after step 4. F4+D4 /= T (T +-3h +-4h /= T). So comparison doesn't work.
If instead the current delta is applied when generating inode caches (both for storing on disk, and for immediate comparison), then the inode cache will have T+D2 in it. Then after step 4, generating a new inode cache for F will yield F4+D4. So, does F4+D4 == T+D2? T +-3h +-4h == T +-1h YES!
"""]]
|
