On Fri, 27 Sep 2013 11:39:19 +0200 Cedric Blancher wrote: > On 27 September 2013 10:24, Glenn Fowler <[email protected]> wrote: > > > > On Fri, 27 Sep 2013 08:12:22 +0200 Roland Mainz wrote: > >> On Fri, Sep 27, 2013 at 7:53 AM, Roland Mainz <[email protected]> > >> wrote: > >> > On Fri, Sep 27, 2013 at 7:24 AM, Roland Mainz <[email protected]> > >> > wrote: > >> >> On Fri, Sep 27, 2013 at 6:48 AM, Roland Mainz > >> >> <[email protected]> wrote: > >> >>> On Fri, Sep 27, 2013 at 6:17 AM, Glenn Fowler <[email protected]> > >> >>> wrote: > >> >>>> On Fri, 27 Sep 2013 04:17:31 +0200 Roland Mainz wrote: > >> >>>>> On Fri, Sep 27, 2013 at 3:50 AM, Roland Mainz > >> >>>>> <[email protected]> wrote: > >> >>>>> > The following code from one of my test scripts no longer work in > >> >>>>> > ast-ksh.2013-09-26 on Solaris 11/AMD64/64bit: > >> >>>>> > -- snip -- > >> >>>>> > $ ksh -c 'redirect {n}<. ; redirect > >> >>>>> > {m}</dev/file/flags@xattr@/dev/fd/$n ' > >> >>>>> > /home/test001/bin/ksh: /dev/file/flags@xattr@/dev/fd/11: cannot > >> >>>>> > open > >> >>>>> > [Invalid argument] > >> >>>>> > -- snip -- > >> [snip] > >> > So basically we're back the point where the whole code within |#if > >> > O_XATTR| doesn't work... and shouldn't be used because the > >> > implementations will perform horribly performance-wise. > > > >> Erm... question: > >> What is wrong with the following patch to fix the original problem > >> that $ ksh -c 'redirect {n}<. ; redirect > >> {m}</dev/file/flags@xattr@/dev/fd/$n ; cd -f $m ; ls;true' # doesn't > >> work: > >> -- snip -- > >> diff -r -u original/src/lib/libast/path/pathopen.c > >> build_i386_64bit_debug/src/lib/libast/path/pathopen.c > >> --- src/lib/libast/path/pathopen.c 2013-08-29 07:17:52.000000000 +0200 > >> +++ src/lib/libast/path/pathopen.c 2013-09-27 08:03:03.149006810 > >> +0200 > >> @@ -222,7 +222,7 @@ > > > >> /* preserve open() semantics if possible */ > > > >> - if (oflags & (O_DIRECTORY|O_SEARCH)) > >> + if (oflags & (O_DIRECTORY|O_SEARCH|O_XATTR)) > >> return openat(dev.fd, ".", > >> oflags|O_INTERCEPT, mode); > >> #if O_XATTR > >> if ((f = openat(dev.fd, ".", > >> O_INTERCEPT|O_RDONLY|O_XATTR)) >= 0) > >> -- snip -- > > > > that looks good but will require this at the top of the file > > > > #ifndef O_XATTR > > #define O_XATTR 0 > > #endif > > > >> Looking at the output of "truss" it seems to do exactly what's > >> requested at shell code level... > > > > there's path corruption somewhere -- more on that later today
> Both Glenn and Roland: Do me a favour and don't break cd -@, do you? > We depend on that feature on production systems, and if you break it I > get nailed by the board of directors. the stream of alphas have been a journey from a collection of sometimes incoherent patches (each patch may have been fine by itself but incoherent in the union) to a readable maintainable implementation with #ifdefs buried as deep in the ast libraries as possible we're not breaking it on purpose although going through the process of molding raw patches into good abstractions I expect a few bugs to crop up -- but I also expect them to be locaized to the abstractions we're debugging the implementation as the patches melt into the mainstream code this latest back-and-forth showed what I was hoping for with O_XATTR: when bugs show up with O_XATTR almost all of them will originate in and be fixed in libast/path/pathcanon.c and libast/path/pathopen.c, which, along with the iffe file libast/features/fcntl.c happen to be the only ast code that references O_XATTR one of my fears of the patch model is that there's sometimes no time to think if we really want to move ast in the right direction we need some breathing room to think and that's why *my* pace of rolling in patches is slower than the list would sometimes like if there's a nice solution in the big picture I rather wait until that gels _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
