On Mon, 8 Jul 2013 00:08:58 +0200 Roland Mainz wrote: > On Sat, Jul 6, 2013 at 8:22 AM, Irek Szczesniak <[email protected]> wrote: > > On Sat, Jul 6, 2013 at 4:31 AM, Roland Mainz <[email protected]> > > wrote: > >> On Thu, Jul 4, 2013 at 7:47 AM, Roland Mainz <[email protected]> > >> wrote: > >>> On Wed, Jul 3, 2013 at 2:06 AM, Roland Mainz <[email protected]> > >>> wrote: > >>>> On Tue, Jul 2, 2013 at 8:04 PM, Roland Mainz <[email protected]> > >>>> wrote: > >>>>> On Tue, Jul 2, 2013 at 4:11 PM, Irek Szczesniak <[email protected]> > >>>>> wrote: > >>>>>> On Sun, Jun 30, 2013 at 11:53 PM, Roland Mainz > >>>>>> <[email protected]> wrote: > >>>>>>> 2013/6/28 Glenn Fowler <[email protected]>: > >> [snip] > >>> Attached (as "astksh20130628_solaris_fixes003.diff.txt") is an updated > >>> version of the patch which fixes the issues which came up during code > >>> review: > >>> - Fixed error handling in cd(1) for NFSv4/CIFS/SMBFS XATTR directories > >>> - Opening the history files now goes through the > >>> |*at()|-emulation&&intercept code to make sure extra flags+signal > >>> restart is handled properly (tested) > >>> > >>> BTW: No, going through the |*at()| emulation is not slower unless the > >>> |fd| argument in |openat(fd,...)| differs between individual calls > >>> (well... at least the code in > >>> http://svn.nrubsig.org/svn/people/gisburn/code/openat_emu/openat_emu.c > >>> did maintain a cache (which is valid until |fchdir()|/|chdir()| is > >>> called) and AFAIK the |*at()|-emulation in libast should do the same). > >> > >> ... one remaining issue came up during review... some code in > >> src/cmd/ksh93 (besides globbing and directory reading) still uses > >> |sfopen()| ... are there ant objections that I switch them over to > >> |sfopenat()| with this patch already (we have to do it anyway in the > >> future to wean-off Shell_t objects from relying on the global cwd) ? > > > > No objection here. IMO all calls to obtain a file descriptor should go > > through openat() because the reasons you've stated, plus the reason > > that open() on such platforms is a libc wrapper which calls > > openat(AT_FDCWD,name,flags,...).
> Erm... the question was mainly for David... near the top of my list is *at()-ifying src/lib/libast/misc/fts.c _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
