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