Ned,

No, no, no. The use of indexes <= 0 in this primitive is UNDEFINED.
Period. That the Windows VM does not fail is a bug in the primitive. The
Windows functions used in that code work on arbitrary file systems some
of which may or may not return what you are expecting. Unless you show
me some documentation that clearly states that the first two entries for
*any* file system which can be accessed on Windows are returned in this
particular order I am going to fix that bug. Which means that with the
next VM it will no longer work.

  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org 
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On 
> Behalf Of Ned Konz
> Sent: Saturday, November 30, 2002 10:00 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: [BUG]3.4-5125 FileDirectory>exists faulty?
> 
> 
> On Saturday 30 November 2002 11:48 am, Tim Rowledge wrote:
> > I've just discovered a nasty side effect of the recent change to
> > Filedirectory>exists (update 5114). The immediate effect is that is
> > stops VMMakerTool from working on Acorn, but I can't see 
> how it works 
> > properly at all.
> >
> > Given the latest CVS platform sources I have (a few days 
> old) it looks 
> > to me that unix, win32 & Acorn all carefully handle _not_ 
> returning an 
> > entry for the directory entry in prim dir_Lookup(). I can't 
> tell about 
> > Mac since the way it works is so foreign to me.
> >
> > The new update seems to rely on the prim actually returning 
> an entry 
> > with quite specific contents.
> 
> Checking again with the 3.4.0Beta2 Mac VM, I see that entry #0 is the 
> parent, and entry #-1 is the directory itself. And entry #-1 returns 
> the name of the directory itself.
> 
> In the 3.2-5 Unix VM I'm using, entry #0 is the directory itself. 
> Entry #-1 returns the same thing. And its name is an empty string.
> 
> In the Windows VM I have, entry #0 is the directory itself. And its 
> name is given as '.'.
> 
> > b) since it looks like it is wrong on win32/unix, why 
> change to match 
> > wrongness?
> >
> 
> Actually, it looks like it's wrong on Mac, and apparently on Acorn as 
> well.
> 
> It seems to be OK on Unix (at least in 3.2-5) (I looked at the code; 
> and if you give it an index of 0 it skips the readdir loop (in which 
> the tests for the '.' and '..' live) and just does a stat() on what 
> you gave it).
> 
> It apparently works on Windows, though if '..' came before '.' it 
> would break.
> 
> On the Mac, it looks like the index is being passed to 
> PBGetCatInfoSync, whose comments say about the index:
> -----------
> If this field contains 0, PBGetCatInfoSync and PBGetCatInfoAsync 
> return information about the file or directory whose name is 
> specified in the ioNamePtr field and that is located in the directory 
> specified by the ioVRefNum field. (Once again, if ioVRefNum contains 
> a volume reference number, the specified directory is that volume's 
> root directory.) 
> 
> If this field contains a negative number, PBGetCatInfoSync and 
> PBGetCatInfoAsync ignore the ioNamePtr field and returns information 
> about the directory specified in the ioDirID field. If both ioDirID 
> and ioVRefNum are set to 0, PBGetCatInfoSync and PBGetCatInfoAsync 
> return information about the current default directory. 
> -----
> 
> However, it looks like we're off by 1 somewhere, as the return value 
> for index 0 is not the current directory.
> 
> Patches welcome. Anyone?
> 
> -- 
> Ned Konz
> http://bike-nomad.com
> GPG key ID: BEEA7EFE
> 
>