On Fri, 14 Sep 2012 06:23:46 +0200 Roland Mainz wrote:
> On Fri, Sep 14, 2012 at 6:01 AM, 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) ?
> More details on the problem with |dup()| sharing attributes like the
> seek position between both old and new fd:
> - I tested /dev/fd on Linux (SuSE 12.1) ... it seems that |dup(15)| is
> not identical to |open("/dev/fd/15", ...)| ... as expected the seek
> position is shared for |dup()| but the fd returned by |open()| has
> it's own seek position
> - AFAIK the issue is irrelevant for pipes/fifos/sockets... right ?
> - What about using |pread()|/|pwrite()| instead of |read()|/|write()|
> on normal, plain files ? This would bypass the issue with the seek
> position being shared...
sfio uses lseek() to maintain stream consistency
if
s1 = sfopen(0, "foo", ...);
s2 = sfopen(0, "foo", ...);
gave the same dup'd fd to both s1 and s2 then all havoc would break loose
remember that streams and associated offsets may cross fork/exec
so its not just a simple matter of maintaining the offset in user space
and using pread/pwrite
_______________________________________________
ast-developers mailing list
ast-developers@research.att.com
https://mailman.research.att.com/mailman/listinfo/ast-developers
