Hi! ----
First to clarify: I like the idea of XATTRs much, however there are issues with the current implementation which need IMO be discussed. Please avoid that this gets a flamewar - the issue is too important to let it drown. Thanks! :-) Joerg Schilling wrote: > > runat(1) are not usable outside a lab environment. First at all these > > extended attribute files need to be made accessible in the normal file > > system name space, otherwise it is just wasted time to deal with them. > > Roland proposed to implement "cd -@ file" in addition to runat(1). Uhm... NO. That was not my patch. I just found it and did some experiements with it (so did David Korn and Glenn Fowler), with the results that the patch will not work. It is a nice technology demonstrator, however in their current form the XATTR implementation makes an integration into a shell very hard, if not even impossible. The patch showed a significant breakdown of various shell features and requires a complete rework. To get the patch fully functional at least the following modificatons needs to be done (for ksh93): - All calls to |open()| needs to be intercepted (which is non-trivial as much of this code sits in libast and other libraries) - All directory operations need to be adjusted, this includes pattern matching, filename completion (vi, emacs, gmacs), file name caching etc. - All functions and builts which operate relative to $PWD need to be made aware that there is the special case PWD=. and that there are directories which live outside the normal namespace - Many of the builtin commands such as "mv", "cp" needs to be modified to support XATTRs in their operations, others need to be made aware about the PWD=. case - All consumers of libshell need to be adjusted, this includes biosh, dtksh, ksh93, tksh and others. Based on these findings the XATTR patch was rejected by upstream (in the case of ksh93 David Korn himself and the complete AST team(!!), including serious doubts about whether the current XATTR implementation is "the right way") and similar work was rejected by the bash people. Unless the XATTR files become accessible from within the "normal" filesystem namespace where each file/directory has a proper parent (even files with files as parent are valid) the normal Unix/Linux/POSIX shells are simply not able to deal with such "alternative universe" files/directories and therefore no such support will be included (at least by upstream). The required adjustents to get this working are just unmaintainable (or better: The maintainers are not willing to handle such a burden). Glenn Fowler suggested (see https://mailman.research.att.com/pipermail/ast-users/2006q2/000928.html) to solve the problem in the file name resolver in the kernel instead of running around madly and trying to make each single application "XATTR"-aware (which is - in the case of the POSIX, bourne and ksh shells - close to impossible). What about creating a new system call (and a property which is inherited to all the process children) which tells the kernel to access XATTR files like the following way: % cd file # will become a valid operation (like in Reiser4) and % cd ... # moves into the XATTR subdirectory Maybe the system call should be seperated for directories and files and allow the usage of prefix or postfix strings to identify XATTR files. Example: The call to |xattrcntl(XATTRCNTL_FILE, XATTRCNTL_SET_POSTFIX, "%%");| will require that a |chdir()| into a attribute file directory is only successfully if for the filename "xyz" the string "xyz%%" is provided. An empty string means that no postfix is required, making % cd "xyz" # a valid operation (unless a prefix was set). Other values for |xattrcntl()| should include |XATTRCNTL_DIR| and |XATTRCNTL_SET_PREFIX|. Comments/suggestions/etc. welcome... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list [email protected]
