> We could try looking for an entry -- any entry -- in the directory in 
> question. If it's not there, the prim should return nil. If it's a 
> bad directory, it should return #badDirectoryPath:
> 
> FileDirectory>>exists
> "Answer whether the directory exists"
> 
> 	| result |
> 	result _ self primLookupEntryIn: pathName index: 1.
> 	^ result ~= #badDirectoryPath
> 
> Does this sound OK? It works for me on the Mac, Unix, and Windows VMs 
> I have available.
Well it's bad logic unfortunately; not all OSs have directories contain
themselves and their parent. I've never really understood anyone would
think that that is a smart thing to do. My understanding was that the
prim code is supposed to filter . & .. out anyway.

I also found out that the change in update 5015 caused infinite
recursion when attempting FileDirectory default directoryExists:'foo'
:-(

Reverting both that change to #directoryExists: and #exists makes me
happy but probably doesn't help a lot. I suppose I must spend some time
looking at AcornFileDirectory etc again. Yuck. I hate that whole
hierarchy, it's such a damned mess.

I think the only 'safe' test is to see if the containing directory (and
that brings in the fun of working out what that is) does actually
contain a directory of the leaf name. At least, until we implement a
decent set of file related prims. It's not terribly common to find an OS
that can't actually take a string and tell us if the file of that name
exists. We probably don't need to manually work it out ourselves for the
general case and certainly not by trying to open the file....

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
The purpose of computing is insight, not numbers.  - Hamming