Rich, A first step at debugging something like this is to try to determine whether it is the posting of the event, or the delivery of the event, that is getting delayed. Looking at the xnu sources, it looks like these events all bottleneck through lock_vnode_and_post(vnode, events). You could try a dtrace script that watches for calls to lock_vnode_and_post (in the kernel), where the second argument has the NOTE_WRITE bit set. See if that seems to correlate with the documentDidSave script running, or when your application receives the event.
The other thing that came to mind is perhaps a NOTE_WRITE isn't getting posted until the file is flushed or closed (or, generally, when the data is actually written to the disk). I don't think that would explain the echo command, since that should end up calling write(2), which goes through VNOP_WRITE, and should post the NOTE_WRITE immediately. However, memory mapped access to a file wouldn't post the NOTE_WRITE until the pageout happens. A pageout could get delayed while the data is dirty in VM, and so you might not see it until the process unmaps the file, calls msync, or there is memory pressure. This is the kind of case where launching a separate process might cause the event to get posted sooner because the process that caused the event exited sooner. Hope that's of some help, -Mark ... who knows nothing about how vnode event delivery happens. > On May 24, 2016, at 9:21 AM, Rich Siegel <sie...@barebones.com> wrote: > > Good morning, > > There are a lot of moving parts here, but I'll try to sketch this out > clearly. :-) > > My application has code which creates a DISPATCH_SOURCE_TYPE_VNODE to watch > for changes in the backing file of an open document. When the source fires, I > look at the flags and proceed based on what they indicate. A NOTE_WRITE means > it's time to reload the document contents from disk, a NOTE_ATTRIB means that > the modification date or some other metadata might have changed, NOTE_RENAME > or NOTE_DELETE for moves, renames, and deletes, and so forth. This code is > all tested and working as it should. > > Next: it's possible for the user to attach AppleScript scripts to certain > actions in the application; for example, a "documentDidSave" script to be > called when saving has completed. > > User scripts can do anything they want (within the confines of AppleScript > execution), and a frequent use case is for users to write a documentDidSave > script that runs the document through some transformation. So, for example, a > documentDidSave script might run "astyle" to reformat source code. > > Here's an extremely simple example of a -documentDidSave script, which adds > "Hello World" to the end of the document that was just saved: > > on documentDidSave(doc) > set d to (the file of doc) as text > set f to POSIX path of file d > set cmd to "echo \"Hello world > \" | cat >> " & quoted form of f > do shell script cmd > end documentDidSave > > What I'm finding is that when this script runs *in my process* as the result > of saving a document, I almost never get a NOTE_WRITE event, and sometimes I > get a NOTE_ATTRIB that doesn't arrive until a couple of seconds after the > script has run. (I have checked, and the file is being changed on disk as > expected.) > > On the other hand, if I run the script manually from the script editor, or > even if I run the "echo" command in a Terminal window, the application *does* > receive a NOTE_WRITE immediately. > > I'm having a lot of trouble figuring out why file system event notifications > would be lost (or not sent) in this situation; it seems oddly specific. I > would expect to always get called when the file is changed, or never, but not > sometimes-depending-on-who-ran-the-script. > > I'd be grateful for any insight. > > Thanks, > > R. > -- > Rich Siegel Bare Bones Software, Inc. > <sie...@barebones.com> <http://www.barebones.com/> > > Someday I'll look back on all this and laugh... until they sedate me. > > > _______________________________________________ > 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/mday%40apple.com > > This email sent to m...@apple.com _______________________________________________ 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
