Re: FSEvents eventid (or perhaps event)'s life
Re: FSEvents eventid (or perhaps event)'s life
- Subject: Re: FSEvents eventid (or perhaps event)'s life
- From: Ron Hunsinger <email@hidden>
- Date: Mon, 30 Jul 2012 17:53:03 -0700
On Jul 30, 2012, at 4:47 AM, Robert Martin <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden