Roland Mainz <[EMAIL PROTECTED]> wrote: Did you omit Davod Korn by intention?
> 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. Why should something that also happens with "runat file" cause problems in a non-broken shell implementation? Note that (in case that you never look at XATTR specifics) you get the same problems with pwd as you get when you are inside a deleted directory. If you look at the error messages from ksh, you see the same message from within a "runat" session and from within an unlinked dir. > 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) Why? > - All directory operations need to be adjusted, this includes pattern > matching, filename completion (vi, emacs, gmacs), file name caching etc. Why? > - 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 This also applies to a ksh that runs inside a removed dir. > - 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 Never try to implement non-trivial commands inside a shell. Why does ksh miss a "tar" builtin? > - All consumers of libshell need to be adjusted, this includes biosh, > dtksh, ksh93, tksh and others. I don't understand this. ... > 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. This proposal - using ... - (from Microsoft in 2001) has been rejected by the POSIX commitee because it is not compatible with POSIX. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
