FileDirectory>>fileExists: (was: Re: [BUG]Unable to load BFAV, various problems )

Tim Rowledge tim at sumeru.stanford.edu
Sun Apr 18 00:07:04 UTC 2004


Ned Konz <ned at bike-nomad.com> wrote:

> > I would suggest a default macro in sq.h that simply implements
> > dir_Exists as interpreterProxy->primitiveFail. Unless of course, all the
> > platformers buy into the idea really quickly and make it pointless.
> 
> Is there some way to extend the idea further to get something like stat() or 
> lstat() instead? Then we could use that for both the exists calls as well as 
> getting other file information. I know that Dave added stat or something like 
> it to his OSProcess plugin.
What are stat and lstat for? How might other OSs provide equivalent
information?


> 
> > A further extension I'd like to suggest is a prim to canonicalize
> > filenames.
> 
> Depends on what you want from it. I can think of a few things one might want:
> 
> * illegal character mapping
> * resolving symlinks
> * removing /./ and /../
> * substituting volume names or aliases
At least in RISC OS that is exactly what it does. Let the OS work out
what on earth is meant by ../../../foo/bar/../wibble.grak - might a
well make it earn its keep. I may be wrong, but given aliases/links is
it not possible that
a/b/c/d/../..
is not neccessarily
a/b ?
(since c might be a link to z/y/x and thus the answer would be, er,
z/y) Now how would we reasonably handle that in squeak code that does
simplistic lexical munging?


> 
> > I certainly have a nice OS call to do that much faster and 
> > much more comprehensively than the current image code (you try
> > understanding the RISC OS filename rules!) and I think *nix can use
> > 'realpath()' at least for directory names.
> 
> The docs for realpath() on my system aren't encouraging:
> 
> "Never use this function. It is broken by design since it is impossible to 
> determine a suitable size for the output buffer."
Ian seems to be using it in some code I spotted, so hopefully it does
actually work sometimes!

An important thing for us to remember here is that there is no reason
all platforms have to have identical FilePlugin implementations. The
codegeneration process is quite able to produce a FilePlugin for *nix
that is very different to one for win* and the platform specific
FileStream/FileDirectory classes can use those differing plugins as
best suited to their needs.

For example, the unix implementation for primLookupEntryIn:index: is
pretty ugly and it would probably be much nicer for unix to have more
direct access to opendir, readdir, rewinddir, blenddir etc. DTL has
already implemented most of this in DirectoryPlugin and it could be
added to FilePlugin for unix.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
99 percent of lawyers give the rest a bad name.



More information about the Squeak-dev mailing list