Tim,

> > > > foo_ self primStat: filename.
> > > > foo ifNil:["didnt find file"]
> > > this would mean that isAFileNamed: can use it, and avoid
> > > *all* worries and complexities involving garbage collection
> We'd want to add this primitive for other platforms besides *NIX.
> Absolutely. Beleive it or not there are currently two ways to check for
> the existence of a file

> Neither is very efficient _except_ in one important way - they can work
> with the very minimalist set of fileprims present in early Squeak. I
> think we can do better with some thought.

A discussion of file system interfaces came up last summer, according to
messages I archived.  Things bogged down on file properties/meta-data.  How
do we move the discourse forward?  I'd have to look, but is there an
existing object model that covers file system notions?

As a Gedankenexperiment, without looking elsewhere yet, I'd think that we'd
want to cover:

	1. Multiple data streams
	2. Metadata dictionary, e.g., Macintosh resource fork, OS/2 Extended
Attributes
	3. Security properties (ACL, owner, group, file attributes)

I claim that #3 can be folded into #2, and that #1 can also be folded into
#2, such that a FileSystemEntry has one or more Stream instances amongst its
properties.  Streams could be read, write, or read-write, with serial or
random positioning.  A FileSystemEntry has a path (in the hierarchy), a name
(property) and one or more properties.  Security could be on the
FileSystemEntry, or possibly associated with properties.  The name space for
the properties allows a hierarchical naming.  Properties are a key/value
pair, where the value can be one of several types, including a stream.
Think analogously of a FileSystemEntry forming the local root of an XML
document, with appropriate attributes and children.

Some operation categories: I/O (read, write, position, setlength), rename,
move, delete, locate/existance, etc.  All file system operations should be
pushed down to the native file system API (and vice versa) as efficiently as
possible.  Objects don't need to be created unless actually used.  So if I
am opening a file, all that appears at first is a FileSystemEntry from which
I can request is location/naming information (convenience methods).  When I
want to perform I/O, I ask for the file stream (convenience method) and just
get it.  I would only see the wider object model (and the properties are
only populated)if and as I access it, e.g., if I were on a Mac and wanted
access to the resource fork.

What would be the overhead, in your opinion, of a mechanism allowing a
property handler to be invoked upon setting a named property?  For example,
setting the "name" property would cause a rename handler to be invoked,
setting a security propery would affect the requested change, as supported
by the underlying file system.  The default property handler would be store
the property, if the underlying file system supported such.

The purpose of this model is not to attempt to force fit new features onto
existing file systems.  Rather, the intent is to allow support within the
general object model without having to bypass it on advanced file stores.

This is shooting from the hip, but I do think there is the germ of something
useful in here.

	--- Noel