As far as I understood the problem, we simply want to notice when something
on the *server* has changed. So it would be enough to compare the
*old server* mtime against the *new server* mtime. No comparsions
with client times, just times valid on the server, so we need not add any
time offsets. Moreover, it should suffice to compare for non-equality, not
for higher/lower time.
|> I'm not saying that the current behaviour can't be improved upon: we sure
|> could improve some of the heuristics. But the patches I've seen so far
|> aren't "it". Take a deep thought about the implications of time skew
|> between the different parties wrt NFS (one implication is that even
|> though the file changed due to _us_ doing the writing, we can't know from
|> the mtime)
Of course, it is theoretically possible that a client modifies something
and because of time skew the mtime doesn't change at all. But we are talking
about an additional criterion to recognize changes. The additional comparison
of mtime should improve things, IMHO, as compared to the current state.
To implement it, we just have to keep the old mtime (unmodified) from the
server in an extra field. Any time a new update is received by the client,
we simply check whether it has changed. This check could be inhibited
if the change were due to ourselves; in this case it is less reliable.
Perhaps somebody has an idea to improve this case without having to
deal with time skews?
-- Thomas