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: Robert Martin <email@hidden>
- Date: Mon, 30 Jul 2012 07:47:50 -0400
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.
-Rob
On Jul 29, 2012, at 8:02 PM, Alfian Busyro <email@hidden> wrote:
> So, this will be more comfortable if I can have my own fseventstd to handle all the events, how do you think ?
> On 12/07/27 19:54, Robert Martin wrote:
>> The IDs relate to the drive, not the system. If you switch to a back up drive of your data, or re-partition your drive, the last event ID will not match the one you stored in user defaults from another drive.
>>
>> It's also possible to corrupt the FSEvent database that's stored on each drive in the .fseventsd file in the root directory.
>> On Jul 27, 2012, at 2:00 AM, Alfian Busyro <email@hidden> wrote:
>>
>>> Just curious how long an event ID (or perhaps an event) will be exist on the system ?
>>> I'd like to store event ID on NSUserDefaults before application terminate itself,
>>> and call it back at the startup to be use in new event stream.
_______________________________________________
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