On Sat, Aug 10, 2013 at 6:09 PM, Glenn Fowler <[email protected]> wrote: > > On Sat, 10 Aug 2013 17:54:56 +0200 Irek Szczesniak wrote: >> 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. > > but isn't "putting resource fork/XATTR support into every utility" exactly > what cd -@ does? > after all, 'cd -@ barf; ls' will affect ls -- will ls need to know its inside > a fork?
No. I don't think so. > > I'm balking at this because I know (but can't enumerate) that -@ infects more > than cd(1) > and the patches for cd -@ are fragile (not the patcher's fault, its weirdnix) Weirdnix here is that you cd(1) into a file. But we've seen this before with reiser4, smbfs and samfs. That's why fstat()/S_ISDIR(fs.st_mode) is a bad idea. > when chunks of code like this are so fragile, at least I want to understand > what's going on > including and especially the scope What's fragile in this case? As long as you don't ask the pwd(1) question in a XATTR directory 'all is well'. > > suppose we finally get cd -@ working to everone's satisfaction > what is the inevitable "add -@ to foo" patch going to look like? > the same fragility, the *same* code? With ls(1) as the exception I don't remember or imagine another consumer of -@. pax(1) doesn't count because its a filesystem in a bottle. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
