On Sat, Aug 10, 2013 at 5:44 PM, Glenn Fowler <[email protected]> wrote: > > On Sat, 10 Aug 2013 17:38:19 +0200 Irek Szczesniak wrote: >> On Sat, Aug 10, 2013 at 5:34 PM, Glenn Fowler <[email protected]> wrote: >> > >> > On Sat, 10 Aug 2013 17:19:29 +0200 Irek Szczesniak wrote: >> >> On Sat, Aug 10, 2013 at 3:36 PM, Glenn Fowler <[email protected]> >> >> wrote: >> >> > >> >> > it still has not been explained why special fs treatment like this >> >> > goes into ksh and not src/lib/libast/something >> >> > is this really something *only* ksh will trip over >> > >> >> IMO yes, because entering a NFSv4 xattr directory is unique for a >> >> shell. Otherwise the only way to do it is to run /usr/bin/runat <obj> >> >> <prog> which is cumbersome at best and useless if you have builtins. >> > >> > how is the chdir()/fchdir() done by cd(1) different from the >> > chdir()/fchdir() >> > done by find(1) or tw(1) or any of the -R commands? > >> You can cd -@ into all filesystem objects and not only directories. >> Links included. And they all have their own resource forks/XATTR. > > ok, but why should/shouldn't the other commands mentioned above be able to > the same?
Because it's a rare and rarely used ability and feature to deal with resource forks/XATTR files? I do understand why Roland did it and Cedric and my people own like it. We're both Apple shops in our labs and the admins need a way to access file files in emergencies. But I'm not convinced that putting resource fork/XATTR support into every utility is a good idea. > maybe I want to pax resource forks and everything > or, don't tell me, read(2)/write(2) don't work on resource forks open(), read(), write(), mmap() all works for resource forks/XATTR. They just don't have a name relative to / because neither Apple, Microsoft or Novell came up with a naming scheme, likely because forks are 'private' to the parent file they are a child node of. Solaris /usr/bin/tar can backup resource forks/XATTR files, but I don't know how to do that. Roland likely knows. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
