Dominic Giampaolo <mailto:d...@apple.com>
November 20, 2015 at 5:09 AM
It's expected if something causes fseventsd to lose track of events
and thus reset its history. The main reasons fseventsd can lose track
of events is if the system crashes or reboots unexpectedly. An event
overrun or fseventsd itself crashing can also cause it but that's
pretty rare. The other thing that can cause it is if a volume is
modified by someone other than an fseventsd capable system. In that
case we don't know what changed and thus have to toss the history and
generate a new volume uuid.
I knew some of that. The volume wouldn't be touched by any non-OS X
systema, but I do regularly boot into newer/older versions of OS X for
testing. Could that cause it?
Generally fseventsd will print a log message when this happens. Check
your recent system logs to see if there are any messages.
I will look for those.
Note that the uuid returned by FSEventsCopoyUUIDForDevice() is not at
all related to the per-volume uuid vended by through the DiskArb api's.
I do understand that this UUID is exclusively for determining if two
FSEvent streams are equivalent, which is what I'm using it for. My issue
was that I was keeping a dictionary with UUID/last-event-id pairs in a
persistent store. What I discovered is, with the UUID occasionally
changing, is that I had one system with almost 200 entries in this
dictionary. Not a big deal, and easily dealt with (I now just toss
entries if they're more than a month or so old), but it was surprising.
Thanks for the info,
James
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
