Provisionally filing this as P2 because it makes a
unit test fail that I wished to work on, not
because of any known user-visible problem. But it
might cause some serious user-visible problem for
all I know.

Using current trunk sources,
GlobFileBuiltQueryTest routinely fails for me.
(Not if I run it in the debugger, of course.) The
failure is at the line

assertTrue("Foo.class created on disk",
fooL.expect(WAIT));

Foo.class here is in a test scratch dir, relative
path build/classes/pkg/Foo.class. The test has
just deleted the whole build/ dir using
java.io.File, refreshed masterfs, and confirmed
that it got appropriate deletion events. Then it
recreates the hierarchy (again using java.io.File)
including Foo.class, calls
FileSystem.refresh(false), and waits for an event.
If it gets a fileFolderCreated event on build/ the
test passes, otherwise it fails.

I am not sure how long this test has been failing
since I have excluded it from commit validation
due to persistent problems on Mac OS X, which are
probably unrelated.

By inserting a lot of logging code I think I have
tracked down the problem, although I don't
understand the masterfs code well enough to
suggest a safe solution.

1. Most of the refreshing appears to work fine.
Control flow passes into
MFO.FCLI.fileFolderCreated as expected.

2. fe.getFile() is the build/ dir. I think this is
the newly created folder.

3. getEventFo gets a hit on the first try, here:

FileObject dFile =
getCache().getValidOrInvalid(getResource().getChild(file.getNameExt()));

4. The cache has an existing binding for build/
which points to a different MasterFileObject. I
think this is the old one - the one that was just
deleted recently.

5. Since currentDelegate != fe.getFile(), no
changes are fired and the test fails.

Note that either of these changes makes the test pass:

1. Skipping the check for currentDelegate ==
fe.getFile() in MFO.fFC.

2. Changing Cache.createReference to use
WeakReference rather than SoftReference, and
calling System.gc() right before refreshing masterfs.

Because #2 makes the test pass, it seems that the
behavior is nondeterministic: sensitive to memory
conditions. This would explain the test passing
when I step through it in the debugger, also.

Anyway this certainly looks wrong: the old build/
file object was deleted earlier. It is now
worthless and should have been discarded from any
internal cache. Perhaps the cache needs to be
cleared when a file is deleted. Which leads me to
another change to masterfs which makes the test pass:

3. Create a method in Cache

void deleted(ResourcePath path) {
    res2DfoMap.remove(path.getNormalizedPath());
}

and add to MFO.FCLI.fileDeleted, right after
fireFileDeletedEvent:

Cache.getDefault().deleted(eventFo.getResource());