On Wed, Dec 11, 2013 at 11:42 AM, Irek Szczesniak <[email protected]> wrote: > On Wed, Sep 11, 2013 at 8:50 PM, Irek Szczesniak <[email protected]> > wrote: >> On Wed, Sep 11, 2013 at 8:40 PM, Glenn Fowler <[email protected]> wrote: >>> >>> On Wed, 11 Sep 2013 20:34:00 +0200 Irek Szczesniak wrote: >>>> On Wed, Sep 11, 2013 at 4:44 PM, Glenn Fowler <[email protected]> >>>> wrote: >>>> > >>>> > On Wed, 11 Sep 2013 16:37:36 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= >>>> > wrote: >>>> >> --047d7b603dccfe0d4104e61c8fa1 >>>> >> Content-Type: text/plain; charset=ISO-8859-1 >>>> > >>>> >> Glenn, this clean up patch is still on hold, right? >>>> > >>>> > yes on hold >>> >>>> Can I ask why? We're talking about >>>> astksh20130829_libcmd_at001.diff.txt, right? The patch which replaces >>>> open() with openat() and sfopen() with sfopenat() and so on? >>> >>>> I have trouble understanding this because it should be a low risk patch. >>> >>> the problem is it only attacks part of libcmd >>> fts, which is the basis for all ast directory traversal, needs to grok >>> *at() too, >>> and its not as straightforward as the other parts >>> >>> why hold off on a partial patch? >>> because based on past experience the day 2 mail flood will start with >>> "none of the -R commands work" >> >> 1. Roland's mail says: "...I've avoided builtins which use fts for now >> to avoid crashes between other work like the fts |*at()| work...". The >> crash part confuses me but the patch itself is pretty clear. >> 2. The -R commands - assuming you're referring to grep -r, cp -r, mv >> -r ... - still work. And if I get the patch right they continue to >> work as long as ((context)?context->pwdfd:AT_FDCWD) points to a >> directory fd which is equal to the process's current working >> directory. >> >> You don't like patches which do changes in multiple steps, do you? >> >> Irek >> >> P.S.: I'm not the one who will scream "bloody murder...none of the -R >> commands work" if its clear that the patch which just went in is the >> beginning of a patch series. I'd start screaming if someone announces >> that the patch series is complete (its obvious that Roland's patch is >> just taking on the easy parts) and then the -R commands don't work. > > Glenn, why again is this patch "on hold"?
Glenn, please... Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
