Modification dates and AFP
Modification dates and AFP
- Subject: Modification dates and AFP
- From: David Feldman <email@hidden>
- Date: Thu, 31 Jan 2002 17:40:13 -0500
I'm working on refining a little Foundation tool I have to synchronize
directories on my desktop and laptop. By and large, it seems to work
OK...uses directory enumerators to compare file modification dates and/or
existence one by one, though there are still some small glitches here and
there. I copy via a system call to ditto and mount the remote directory via
AFP so all the Mac OS metadata and resource fork stuff gets copied properly.
But there's a really annoying problem when the two machines' clocks are even
a second or two off from one another, which is not an unusual occurrence.
Eventually I'd love to be able to distribute this app, and if this
particular bug can be eliminated that would be good.
The problem, as far as I can tell, is this: When Computer (A) mounts a
shared volume from computer (B), it compensates for clock differences, which
in many cases would be good. So, for example, (A) thinks it's 12:00 and (B)
thinks it's 12:05. Now I take a file on (A) and copy it to the mounted
directory. If I look at the new file on (A), the mod date appears the same.
But if I look at it using (B), the mod date is adjusted for the clock
discrepancy, i.e. 2 minutes later.
However, if between mount sessions one of the clocks is changed, the file
modification dates on its disk are obviously _not_ changed. Continuing my
example above:
- Right now if I compare the two files using (A) their mod dates are
identical.
- I unmount the directory, synchronize the clocks, and remount it. (I think
AFP may not notice if the clocks change while the directory is mounted,
though I'm not positive of this.)
- Now if I compare the files using (A), the copy should read as 2 minutes
newer.
- I copy the copy back over the original. Time has been wasted but no real
harm done.
- If (B)'s clock gets ahead again and I re-mount and re-compare, the same
thing happens in reverse. The file on (A)'s disk now reads as newer.
For the most part, this is inconvenient: A synchronization that should take
2 minutes takes 20 instead, and cancelling mid-sync seems to do nasty things
to my filesystems sometimes so should generally be avoided. But it's REALLY
inconvenient if I'm trying to do a sync and run out the door. The only
actual potential for data destruction is with any files that have
legitimately been modified within the time difference between the two
clocks, which are rare.
Anyway. I'm starting to be fairly sure this is how it all works, but that
doesn9t really bring me closer to a solution. I haven't found a way to test
the discrepancy manually and adjust, so the best I can do is either make
sure the clocks are synced before running, or code in a 2-second margin of
error, within which mod date differences won't be recognized. Neither
solution is great. Can anyone suggest something better?
Thanks!!!
--Dave