Re: Modification dates and AFP
Re: Modification dates and AFP
- Subject: Re: Modification dates and AFP
- From: Evan Coyne Maloney <email@hidden>
- Date: Mon, 4 Feb 2002 13:02:16 -0500
There's also the problem of long-term clock skew, where one clock gains,
say, 1 millisecond every day, and the other clock doesn't.
My experience is that it's impossible to build a usable solution based
solely on timestamps and file sizes. I had a similar problem writing a
peer-to-peer filesharing app a while back, and my solution was to use
timestamps, file sizes and even file names only as a "hint". To compare
files, I used an MD5 hash of each file, and compared that. (You can also
use SHA-1 or whatever's convenient.)
In pseudocode, the check I did was:
1. If "timestamp" of "file a" == "timestamp" of "file b"
and "size" of "file a" == "size" of "file b"
and "filename" of "file a" == "filename" of "file b"
then assume the files are the same.
2. OTHERWISE, compare MD5 hashes of files...
If "md5-hash" of "file a" == "md5-hash" of "file b"
then assume the files are the same.
3. OTHERWISE, you've got different files, bud.
If you can compute MD5 hashes in the background (if you have a daemon, for
example), then you can assume MD5 computation is fairly cheap (because you
don't have to do it while the user is waiting). If that's the case, you can
dispense with the hints and only do an MD5 comparison.
Hope this helps,
Evan
On Thursday, January 31, 2002, at 05:40 PM, David Feldman wrote:
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
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
Evan Coyne Maloney____________________________________________________
The six-legged fire-breathing dog email@hidden