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. I'm puzzled; obviously I could change the Acorn VM but a) it would break backwards compatability (big deal eh? nobody uses Acorn Squeak you think? Wrongo, dude, wrongo) b) since it looks like it is wrong on win32/unix, why change to match wrongness?
I wonder when we will actually get a filename system that works cleanly... sigh.
tim
Tim,
This is *weird*. It relies on two bugs at once: For one thing primDirLookup does not test if the index is zero (and I think it should) and then dir_Lookup() must return (I *think*) a directory entry which actually describes the directory you are searching in where it really should fail since that entry does not exist. I'd like to know who came up with that ;-) BTW, it is inconceivable for me that this actually works on Windows (which for some strange reason it does).
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Tim Rowledge Sent: Saturday, November 30, 2002 8:48 PM To: squeak-dev@lists.squeakfoundation.org Subject: [BUG]3.4-5125 FileDirectory>exists faulty?
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. I'm puzzled; obviously I could change the Acorn VM but a) it would break backwards compatability (big deal eh? nobody uses Acorn Squeak you think? Wrongo, dude, wrongo) b) since it looks like it is wrong on win32/unix, why change to match wrongness?
I wonder when we will actually get a filename system that works cleanly... sigh.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful Latin > Phrases:- Fac ut vivas. = Get a life.
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,
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@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Saturday, November 30, 2002 10:00 PM To: squeak-dev@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
On Saturday 30 November 2002 01:36 pm, Andreas Raab wrote:
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.
In fact, I know that there are file systems available to Windows in which this is not the case, having helped write the NT backup API...
I did feel uneasy about it because of that. So here's my attempt at improving it:
How can we best code FileDirectory>exists, so that it'll be compatible with old VMs?
We don't really want to iterate through the parent directory contents.
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.
Ned,
FileDirectory>>exists "Answer whether the directory exists"
| result | result _ self primLookupEntryIn: pathName index: 1. ^ result ~= #badDirectoryPath
This looks reasonable to me.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Ned Konz Sent: Saturday, November 30, 2002 11:13 PM To: squeak-dev@lists.squeakfoundation.org Subject: Re: [BUG]3.4-5125 FileDirectory>exists faulty?
On Saturday 30 November 2002 01:36 pm, Andreas Raab wrote:
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.
In fact, I know that there are file systems available to Windows in which this is not the case, having helped write the NT backup API...
I did feel uneasy about it because of that. So here's my attempt at improving it:
How can we best code FileDirectory>exists, so that it'll be compatible with old VMs?
We don't really want to iterate through the parent directory contents.
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.
-- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE
On Saturday 30 November 2002 02:22 pm, Andreas Raab wrote:
FileDirectory>>exists "Answer whether the directory exists"
| result | result _ self primLookupEntryIn: pathName index: 1. ^ result ~= #badDirectoryPath
This looks reasonable to me.
Yes, but it won't work with the current VMs (at least the Unix one). I recall now (after trying to run the tests) that the caching in the VM is keeping testDeleteDirectory from working.
Basically, it does this:
creates subdir zTestDir in default dir asserts that it exists deletes the subdir (which works) asserts that it doesn't exist (which doesn't work, because of the caching).
Apparently there is no invalidation of the cache that dir_lookup() uses in this case.
Try to get the FileDirectoryTests to run.
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
On Saturday 30 November 2002 02:45 pm, Tim Rowledge wrote:
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.
This doesn't assume that the directory contains anything at all. It just depends on the prim returning nil or an entry for index 1 (which it should), or #badDirectory if the directory isn't there.
Unfortunately, it's broken in Unix and Mac because of directory caching in dir_lookup() that isn't invalidated when you delete the directory you just looked in and then try to look in it again (which is what the FileDirectoryTests do in testDeleteDirectory.
Ned Konz ned@bike-nomad.com is claimed by the authorities to have written:
This doesn't assume that the directory contains anything at all. It just depends on the prim returning nil or an entry for index 1 (which it should), or #badDirectory if the directory isn't there.
Ack, you're right - I failed to look at the second line and follow the full logic.
Unfortunately I will _still_ have to change te Acorn file plugin code because I made a mistake six years ago. :-( A dud directory name is not being checked for until AFTER the 'no more files' condition, which means that a #badpath doesn't actually get returned for a bad path. Foo.
We really need to do better at specifying this stuff. Hmm, sounds like normal software industry.....
tim
squeak-dev@lists.squeakfoundation.org