FSEvents eventid (or perhaps event)'s life

  • Hi, All.

    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.

    Regards,
    Alfian.
  • 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.

    HTH,
    Rob

    On Jul 27, 2012, at 2:00 AM, Alfian Busyro <alfian.busyro...> 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.
  • Thanks,
    So, this will be more comfortable if I can have my own fseventstd to
    handle all the events, how do you think ?

    Regards,
    Alfian

    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.
    >
    > HTH,
    > Rob
    >
    > On Jul 27, 2012, at 2:00 AM, Alfian Busyro <alfian.busyro...> 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.
    >
  • 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.busyro...> 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.busyro...> 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.
  • On Jul 30, 2012, at 4:47 AM, Robert Martin <robmartin...> 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
  • Thanks for all replies.

    Now I know that event ID is related with device UUID.
    And about FSEventStore, I google it but I can not found any information
    of this.
    can you provide some information of this ?

    Alfian.

    On 12/07/31 9:53, Ron Hunsinger wrote:
    > On Jul 30, 2012, at 4:47 AM, Robert Martin <robmartin...> 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
  • On 30 Jul, 2012, at 17:53, Ron Hunsinger wrote:

    >
    > On Jul 30, 2012, at 4:47 AM, Robert Martin <robmartin...> 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

    FSEventsCopyUUIDForDevice is the correct way to read the event store UUID.

    - m

    >
    > -Ron Hunsinger
previous month july 2012 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
Go to today