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 <alfian.bus...@kddi-web.com> 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 <alfian.bus...@kddi-web.com> >> 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 (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
