Actually I decided to refine the semantics of change events somewhat. If the added and removed sets are null, then clients should interpret that to mean that *something* in the directory changed, but the filesystem doesn't know what. In that case, clients should be conservative about updating their state w.r.t. to the changed entry and its children. Otherwise, if the added and removed sets are non-null, then clients can precisely update their state. And, furthermore, the filesystem will now drop change events that have added and removed sets that are BOTH empty. This prevents the second change event (from the file watcher) from getting through after an internal file creation, e.g., The only bad news is that this requires significant change to the project manager and find in files change handlers. The good news is that that's been done :)