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
