> > Ok, I see why that fixes it...but:
> > 
> > A) why are you looking at the first item and not the zero-th?
> 
> Because entry zero is plain UNDEFINED. That the primitive 
> doesn't fail for index <= 0 is a bug in the primitive.

Sounds reasonable...previously, this method checked the zero-th entry
and I was wondering why the change.  It appeared that the zero-th entry
was "." (representing the current directory).  And, there was no such
entry for "c:".
 
> > B) why isn't the primitive answering the directory entries 
> for 'c:' or 
> > 'c:\'?
> 
> What do you mean?! What is wrong with any of the following?
> 	FileDirectory root entries
> 	(FileDirectory on:'c:') entries
> 	(FileDirectory on:'c:\') entries	

On second glance there appears to be nothing wrong with these.  They do
not appear to answer a "." entry and that's what was tripping up the
code in change set 5114.  I suppose since "." isn't really an entry
anyway, it's more correct that it not be included.

> > C) this assumes that every directory has at least one
> > entry...
> 
> No it does not (one of the subtleties of that fix which 
> should be documented). It only assumes that the return value 
> will *NOT* be "bad path".

Ah...good.

Anyway, Ned's fix to his fix (which appears the most correct to me)
should get in ASAP, because as it is right now, it's broken.

- Stephen