Missing specific FSEvents after restart
Missing specific FSEvents after restart
- Subject: Missing specific FSEvents after restart
- From: James Bucanek <email@hidden>
- Date: Mon, 13 Sep 2010 17:43:16 -0700
Greetings,
I've spent a week tracking down a really strange problem with a
customer. I'm author of a backup solution for OS X that uses
FSEvents to determine which directories need capturing, but
change events for one particular folder of one particular
customer doesn't appear in the FSEvents history.
Before I file a bug report, I wanted to run this problem past
the list. I'm also trying to figure out if this is an OS X issue
or a VMWare issue.
Here's exactly what happens:
The customer is using VMWare to run an instance of Windows in a
virtual machine.
- After starting up and shutting down Windows, the data files in
the VM image package have been modified. This can be verified by
the last-mod dates on the files.
- Live file system change events for this folder are apparently
being broadcast. When my customer runs a utility like FSEventer
(cool app, BTW), they report that the VM Image package appears
in the list of modified folders.
- If the customer immediately runs my backup utility, a historic
FSEvent for the VM Image folder is received and it gets backed up.
So far, so good. Here's where things go wrong.
- Repeat the process (start up VM, shutdown VM, verify that
files were modified).
- Restart the computer.
- The customer runs my backup software after the restart. It
requests the historic FSEvents for the entire volume, using a
starting event date that precedes the most recent VM image
package modifications, but it receives NO events for the VM
Image package directory (other change paths all appear valid).
Naturally, it ignores the directory during the backup.
This actually came as shocking news to me, as I've had great
success using FSEvents and I've never seen it "lose" a change event.
What first seems odd is that the live feed of FSEvents includes
a change event for this path, but the history replay doesn't.
It's as if fseventsd gets the event but doesn't coalesce it
and/or write it to disk.
My process is running as root, so there's no security
restrictions masking the event. (It shouldn't matter anyway,
since the VM files are in the user's ~/Documents folder with
normal ownership and privileges.)
My customer has verified that the same problem affects Time
Machine. That is: start VM, stop VM, restart OS X, run Time
Machine, and the VM files are not copied.
My customer has also verified that the same thing happens on two
different laptops, both running 10.6.
I had them rename their /.fseventsd folder and restart (creating
a brand new .fseventds folder and try again. They got the same
result. I had them send me their old .fseventsd folder if this
would be useful to include in a bug report.
Could this be a VMWare issue? I know that many virtual machines
don't interact with the host OS through the normal APIs, and
thought that it might somehow be going behind OS X's back, so to
speak. But what's odd is that the live events include the
directory and the file mod dates do get changed.
My suggested workaround was not to run Windows. [ Patient:
"Doctor, it hurts when I run Windows." Doctor: "Don't run
Windows." ] But, sadly, this wasn't acceptable to my user. :(
Thoughts? Suggestions? I'm totally scratching my head at this point.
Thanks,
James
P.S. I don't have a copy of VMWare to test with.
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden