On Jul 30, 2012, at 4:47 AM, Robert Martin <robmar...@frontiernet.net> wrote:
> Just keep track of the device UUID for each path and last event ID that
> you're tracking. EventID's are tied to each device, so you have to know that
> the device has not changed behind your back. For example, this can happen if
> the user has switched to a cloned backup drive containing the folders you are
> tracking. If the UUID's don't match, you can alert the user and rebuild
> whatever it is you're doing.
What you need to track is the UUID of the FSEventStore, together with the last
event ID.
That is, there are three relevant IDs:
The volume itself has a UUID
Each volume has its own FSEventStore, with its own UUID
There is an event ID, that is meaningful only with respect to its
particular FSEventStore
The FSEventStore gets invalidated and discarded at the slightest hint of
trouble; most commonly any time the volume is not unmounted properly. A system
crash, of course, fails to unmount any volume correctly, so it invalidates the
FSEventStores of all volumes mounted at the time. A full OS install seems to
also invalidate the FSEventStore.
The volume's UUID persists across all those things, but not across an erase.
You can use it to be sure you're referring to the proper volume.
You can get the volume's UUID from diskutil info. You can read the
FSEventStoreUUID from /.fseventsd/fseventsd-uuid
-Ron Hunsinger
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
