Re: viewprinting: what format should views be stored in?

[George Beshers]

First a little (tentatively) suggested terminology---translation of (tentatively) I stand behind it until I begin to suspect I've made a mistake and then I change sides ;-) : 1) A mask consists of a set of prescriptions (trying to avoid rule) which defines a     subset of permissible functionality for a file system. 2) The permissible functionality of a file system is roughly speaking, the ACLs     for all the objects in the file system.     Actually, I think this is a good place to start, because the type "permissible     functionality" is in fact what the mask is applied to and what is returned.    Grant you evaluation is done lazily as the execution of an application requires it. 3)  A user and group instantiated mask forms an operational set of functionality.      What is important here is to recognize that a given executable may have      different apparent functionality based on who is running it.      To make this concept clearer, consider the possibility that group write access      to a file might be elided (masked away) by the some prescription for a user      who otherwise might have add access---but the user's privileges are limited      by the executable. Hans Reiser wrote: It is very important that we have something simple that reuses code for this purpose, and it also needs to be scalable.  That is, we need to be able to determine in insignificant time whether a file passes through a mask consisting of a million files. A million files or a million rules?  A single rule may give access to a million files and     require only constant time to evaluate. One approach would be to use a format similar to that for chroot, that is, to keep the format we use for directory trees now, and use it for storing the mask.  This raises the question: how would the format for the mask differ from that of the underlying filesystem. Another approach is to use stem compressed names, or some other unique within the fs format for the mask. Can you elaborate on this for a newbie We need to be able to support specifying a mask that allows any file within a given directory to be visible.  That is, we need to support dirname/* but we don't yet need to support dirname/foo.* NB.  Hans and I had discussed limiting access to 'hidden files' informally:  '..' in particular needs some special attention although it would be best not to have a special case if we can avoid it. We probably don't want to allow symbolic links to be followed unless where they point to is within the mask. Agreed. I want minimal code but I want it to be treelike in its performance scalability. Ideas? Well, for the moment only more questions: Suppose we have a file system and a mask.  If we were to create a chroot by copying just the file system accessible through the mask and run the application in that environment would the semantics of running the application on the original file system with the mask by equivalent.  By equivalent I mean no observable difference in the instructions executed at the user level or the output generated. Does the question make sense?