>> Are we missing something at the [file] primitive layer?
> A decent way to handle file attributes such as type/creator/permissions.

But how do you describe this in a way that is portable between Unix file
permissions and SMB (Samba, Win32, OS/2) ACLs?

Hans-Martin Mosner asked about Resource Forks.  OS/2 supports the notion of
extended attributes.  These are similar to Resource Forks: data "associated
with" a file, and accessed as a key-value pair.  The Windows Registry system
also supports key-value access, although the key-space is hierarchical
instead of flat.

Let me toss out a strawman proposal to collectively address these issues as
follows: for each file there can be an optional key-space associated with it
(a Dictionary in Smalltalk terms) containing meta-data.

On the Macintosh, this key-space would provide access to the resource fork.
On OS/2, this would provide access to extended attributes.  On all systems,
security properties can be mapped into this meta-data key-space using
reserved keys.  Systems that support multiple data forks could map them
using reserved keys associated with streams.

For that matter, the approach could be reused to cover the Windows Registry
API, in as much as the hierarchical nature of the Windows Registry can
mapped as a dictionaries of dictionaries, although overriding the access
methods to support direct use of the hierarchical keys would be a goodness.

I realize that not everything here is a primitive, but the proposal directly
addresses the security and resource/attribute issues raised for inclusion as
primitives.

	--- Noel