Marcus Brinkmann wrote: > All objects are derived from a polytype class, which provides the > following interfaces: > > error_t poly_get_supported_types (obj_t obj, type_spec_t types[]); > error_t poly_get_facet (obj_t, type_spec_t new_type, out: obj_t > new_obj);
> Using the poly-type approach would remove all ambiguities: Applications > would either see a file or a directory, but not both. Applications who > _know_ about hybrid types can use the new functions to switch facets > explicitely. If a user wants to use an application with a hybrid type, > he will have to make his intent explicit by providing the node with the > right facet type to the application. I haven't catched up on this topic yet, but Hans Reiser has similar problem with his reiser4 and multiple streams for one file: <http://www.namesys.com/v4/v4.html#files_dirs>. Perhaps it's worth to learn what reiser4 does about it. I remember that there was some proposal in POSIX to handle metadata as files by using special file name component "..." (3 dots), e.g. file/.../stat/mtime is file with last modified time. (Example is mine and I don't know if the proposal was exactly for that. The same applies for the other examples in this mail.) Anyway, this "..." was rejected, but it could be used to access facets of any file (or directory). So directories could become real directories and not files in the Hurd and their raw content may be accessed only by something like "dir/.../raw". Extended attributes can be accessed by this file thing too. The tar.gz case could be something like "package.tar.gz/.../facets/untar". Of course, there are problems with this: 1. "..." becomes special file name component and can't be used for anything else, just like "aux" in another OS. 2. Some of these /proc-like files has no inode number and this may impose significant problems. Regards, ogi _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
