On 17 September 2012 17:00, Roland Mainz <roland.ma...@nrubsig.org> wrote: > On Mon, Sep 17, 2012 at 3:17 PM, Lionel Cons > <lionelcons1...@googlemail.com> wrote: >> On 14 September 2012 06:01, Roland Mainz <roland.ma...@nrubsig.org> wrote: >>> Attached (as "astksh_chroot_cd_devfd_cd_f_20120911_001.diff.txt") is a >>> patch which fixes two issues with "cd": >>> 1. $ cd /dev/fd/$fd # doesn't work in chroot'ed environments when >>> /dev/fd is not mounted (thanks to CERN staff for reporting this). >>> 2. POSIX does not mandate _any_ paths. Since doing a "cd" relative to >>> a directory fd has become very popular the request was made to add an >>> alternative to using /dev/fd which is more or less acceptable for the >>> POSIX people. Based on that and a few discussions I added the option >>> -f to cd that a directory descriptor can be passed and the path given >>> is relative to that file descriptor. >>> >>> Notes: >>> - The code introduces a new function called |pathdevfd2relpathfd()| in >>> libast which can extract the fd number from a /dev/fd/$fd path (even >>> nested) >>> - If files or directories are opened relative to /dev/fd/$fd/$path >>> |sfopen()|/|sfopenat()| will now bypass the /dev/fd filesystem >>> completely (which gives a nice performance boost). The only exception >>> is that this can *NOT* be done for a plain /dev/fd/$fd, e.g. >>> /dev/fd/15. The problem is that there is AFAIK no way to open a file >>> from a file descriptor without using the /dev/fd filesystem or using >>> |dup()| ... but |dup()| rules itself out because the resulting >>> "cloned" fd still shares attributes like the current seek position >>> with the original fd... >>> >>> Glenn: Is it acceptable for |sfopen()| to |dup()| the incoming file fd >>> (see "Notes" above) ? >> >> Roland: Are you going to send your new patch to this list? The >> feedback of Josef's group has been very positive and rigid testing >> didn't show any problems. > > Attached (as "astksh_chroot_cd_devfd_cd_f_20120916_002.diff.txt") is > the patch which adds $ cd -f $fd relpath # and the /dev/fd emulation > for chroot environments and older Solaris releases. > > Changes: > - It's intentionally no longer possible to mix $ cd -f $fd ... # with > absolute paths. As we figured out this (together with the idea that > multiple /dev/fd/$fd could be stacked (they can... but it's not clear > whether the results would be relative or absolute paths (basically > it's disputed))) will quickly cause breakdown of semantics, logic and > the universe > > Notes: > - $ cd -f $fd relpath # more or less creates a "virtual /" at the > directory where $fd points to. Doing a cd .. below that point is NOT > supported and may result in undefined behaviour. This is more or less > a limitation of the underlying technology and semantics... but as we > figured out it should not represent an issue for real-world script > programming
The patch looks good. I'd have my staff review and test it, too. Benchmarks: Are there any shell benchmarks out there which measure time to move files? Based on a preliminary sort test (sort files into subdirs), the previous patch reduces the time to move files down to almost - INCREDIBLE! - 20% of the original value on a NFS filesystem (RH Linux as server) for two paths (src and dest, both reduced to ~{srcfd} and ~{destfd} or /dev/fd/$srcfd and /dev/fd/$destfd) > 2048bytes with 128 path elements. Lionel _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers