Re: Missing specific FSEvents after restart
Re: Missing specific FSEvents after restart
- Subject: Re: Missing specific FSEvents after restart
- From: James Bucanek <email@hidden>
- Date: Tue, 14 Sep 2010 15:37:53 -0700
Dominic,
Thanks for the feedback.
I don't think that is the case here (a long running daemon
making changes after fseventsd has exited), although I wouldn't
be surprised if something like that were also going on.
I had them start and stop their VM, and then immediately run a
backup. In this case (without restarting) the backup received a
change event for the VM image package and captured it. I also
had them run FSEventer at the same time, and they reported that
when they started and stopped their VM a change event for their
VM Image directory appeared.
That's was so weird to me; that it appears that a file system
change event was broadcast for that folder, but somehow doesn't
end up in the historic record of events. I wouldn't have all
been surprised if VMWare was poking around the disk image at the
driver level and bypassing FSEvents, but then I wouldn't expect
to get one under any circumstances.
Caveat: I can't verify all of these details myself; I'm taking
the word my of my customer here re the sequence of events and
what FSEventer reported. I've had trouble getting this user to
follow directions exactly, so a light sprinkling of salt is in order.
As I mentioned, I had them capture their /.fseventsd folder and
I have my app's log records showing what FSEvents my app
received in the case of restarting and not restarting after
running their VM. I can provide this (in a bug report or
separately) if it would help.
James
Dominic Giampaolo <mailto:email@hidden> wrote (Tuesday,
September 14, 2010 12:37 PM -0700):
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.
If what I think is happening is in fact happening then it's a
tricky issue.
We've seen cases where this occurs because the process
making changes to the files exits *after* fseventsd exits
and so fseventsd never sees the change. In the case of
VMware, although they may have exited the VM there are
still background processes that may continue to update
state (I know this is true with Parallels and I expect it to be
the same with VMware).
It would be interesting to get the output of:
sudo ls -lT /.fseventsd
and then "ls -lT" on the files that should have been
reported as modified but were not.
I'd also need to see the timestamp on when the system
was rebooted (which should be in /var/log/system.log).
If the files were modified after fseventsd exited, then
it's hard for us to do much about that. The fseventsd
process is supposed to be one of the last things that
exits before the system reboots. However we don't have
control over third party apps/daemons/code and so there
is no way to enforce it.
--dominic
--
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