thanks for the info
On Fri, 30 Aug 2013 21:01:04 +0200 =?KOI8-R?B?z8zYx8Egy9LZ1sHOz9fTy8HR?= wrote:
> This may be misleading:
> cat xattrtest1.c
> #include <stdlib.h>
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
> int main(int ac, char *av[])
> {
> int dirfd;
> int xattrfd;
> dirfd = openat(AT_FDCWD, "foo", O_CREAT|O_RDONLY|O_NONBLOCK,0666);
> xattrfd = openat(dirfd, ".", O_RDONLY|O_XATTR);
> fchdir(xattrfd);
> system("/bin/pwd");
> chdir("..");
> system("/bin/pwd");
> return (EXIT_SUCCESS);
> }
> $ truss ./a.out 2>&1 | fgrep chdir
> fchdir(4) = 0
> chdir("..") Err#20 ENOTDIR
> This makes sense. As the Exceed Windows NFS server people say, the
> O_XATTR directories have a life time as long the directory is open,
> and used, and afterwards its discarded, and rebuild anew from Window's
> list of alternate stream data.
> On Solaris its different, the O_XATTR directories are real
> directories, but have no parent. The /sbin/sh, /bin/sh, /usr/bin/sh,
> /usr/bin/csh, /usr/bin/bash etc shells have the convention that doing
> a cd .. in a O_XATTR returns to the filesystem node the O_XATTR
> attributes are for, but this is only a convention at shell level, and
> not at C level.
> This might be confusing, until you notice that Solaris utilities do
> not use openat(fd, ...,O_XATTR), but instead use attropen():
> NAME
> attropen - open a file
> SYNOPSIS
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> int attropen(const char *path, const char *attrpath, int oflag,
> /* mode_t mode */...);
> DESCRIPTION
> The attropen() function is similar to the open(2) function
> except that it takes a second path argument, attrpath, that
> identifies an extended attribute file associated with the
> first path argument. This function returns a file descriptor
> for the extended attribute rather than the file named by the
> initial argument.
> The O_XATTR flag is set by default for attropen() and the
> attrpath argument is always interpreted as a reference to an
> extended attribute. Extended attributes must be referenced
> with a relative path; providing an absolute path results in
> a normal file reference.
> RETURN VALUES
> Refer to open(2).
> But seriously, *STRONGLY* prefer to deal with this using cd -@, and
> have cd .. use the parent node name to return me to the parent node,
> as the original patch for cd -@ did.
> That is much more *user* friendly.
> For scripts it may be better to extend /dev/file/ to have /dev/file/xattr:
> ksh -c 'mkdir -p foo2 ; redirect {d}<foo2/ ; redirect
> {n}<>/dev/file/xattr:/dev/fd/$d/myxattr ; print -u$n "bla" ; cd -@
> foo2 ; ls ; cat myxattr' myxattr SUNWattr_ro SUNWattr_rw
> bla
> Olga
> On Fri, Aug 30, 2013 at 7:40 PM, Simon Toedt <[email protected]> wrote:
> > On Fri, Aug 30, 2013 at 6:32 PM, Glenn Fowler <[email protected]> wrote:
> >>
> >> On Fri, 30 Aug 2013 10:00:35 -0400 Glenn Fowler wrote:
> >>> On Fri, 30 Aug 2013 13:04:17 +0200 Simon Toedt wrote:
> >>> > On Fri, Aug 30, 2013 at 7:11 AM, Glenn Fowler <[email protected]>
> >>> > wrote:
> >>> > >
> >>> > > On Fri, 30 Aug 2013 04:53:04 +0200 Cedric Blancher wrote:
> >>> > >> On 29 August 2013 19:45, Glenn Fowler <[email protected]> wrote:
> >>> > >> >
> >>> > >> > the AT&T Software Technology ast alpha 2013-08-29 source release
> >>> > >> > has been posted to the download site
> >>> > >> > http://www.research.att.com/sw/download/alpha/
> >>> > >> > the package names and md5 checksums are
> >>> > >> > INIT 132e0403af573fa1cb1e202267fedeb8
> >>> > >> > ast-open 334615fb3a652575106194c281d27b5c
> >>> > >> > ast-ksh ebcc56d9ab673aaafbb163d6eee1a93c
> >>> > >> > the md5 sums should match the ones listed on the download page
> >>> > >> >
> >>> > >> > this is still a work in progress, but we are getting closer to a
> >>> > >> > beta
> >>> > >
> >>> > >> No, you don't. This release if OFFICIALLY broken beyond usability
> >>> > >> and USELESS.
> >>> > >> You really had to try and tinker with cd -@ again, did you? I'm
> >>> > >> really
> >>> > >> angry. cd .. no longer works within NFSv4 xattr directories, e.g.
> >>> > >> echo "" >x ; cd -@ x ; touch xattr ; cd .. ; rm x now fails with a
> >>> > >> cd:
> >>> > >> /home/ced/prod4/test19/x//@//..: [Not a directory]
> >>> > >
> >>> > > hey gsf, there's a problem with the way you did foo
> >>> > > here's a sequence of commands / code that shows the problem
> >>> > >
> >>> > > its a bug
> >>> > > patch is below
> >>> > > with ksh builtins like wc you should be able to do things like
> >>> > >
> >>> > > wc /home/ced/prod4/test19/x//@//xattr
> >>> > >
> >>> > > and you get a pwd that can be passed on to other processes and used
> >>> > > long after your process dies
> >>> > >
> >>> > > /home/ced/prod4/test19/x//@//
> >>
> >>> > Is this some late Aprils Fool joke or is this serious? How do you
> >>> > prevent that someone clobbers his path together from variables or
> >>> > through printf and accidentally creates a path like that?
> >>
> >>> > ksh -c 'typeset -a a=( /foo bar /baz/ /@ / /append/ /bum ) ; IFS="/" ;
> >>> > printf "%s\n" "${a[*]}"'
> >>> > /foo/bar//baz///@////append///bum
> >>
> >>> > That strikes me as extra risky strategy.
> >>
> >>> alright
> >>> I got most of the feedback I needed to understand the (non-)namespace
> >>> working on an update
> >>
> >>> I do have one more question from the first "cd -@" example
> >>
> >>> cd -@ t.c
> >>> cd ..
> >>
> >>> if t.c is a regular file and O_XATTR(t.c) really hangs in a nameless part
> >>> of the filesystem
> >>> how can ".." inside the O_XATTR(t.c) xattr dir have any meaning other than
> >>> ".. points to the parent object"
> >>> indeed ls -ail inside O_XATTR(t.c) shows .. as a regular file
> >>> and /bin/pwd (without hints from $PWD) chokes because .. is not a
> >>> directory
> >>
> >>> so if the sequence
> >>> cd -@ t.c
> >>> cd ..
> >>> really does get you back where you started in a solaris shell:
> >>> how does the documentation rationalize that?
> >>
> >> I think I have the answer to my own question
> >> when you "cd -@" you are not in a place named by a path but instead in a
> >> place named by an fd
> >> so all relative paths in that fd dir are relative to the fd
> >> which then makes "cd .." from within "/dev/file/xattr@somepath" ambiguous
> >> when viewed
> >> as a path operation "/dev/file/xattr@somepath" + ".." =>
> >> ""/dev/file/xattr@somepath/.." (ambiguous)
> >>
> >> I don't have a solaris with a shell with working "cd -@"
> >> what is is the output of the sh pwd in a solaris /bin/sh:
> >>
> >> cd -@ t.c
> >> cd ..
> >> pwd
> >>
> >
> > /sbin/sh -x -c 'echo "" >foo ; /bin/pwd ; cd -@ foo ; /bin/pwd ; cd ..
> > ; /bin/pwd ; :'
> > + echo ''
> > + 1> foo
> > + /bin/pwd
> > /home/sim
> > + cd -@ foo
> > + /bin/pwd
> > pwd: cannot determine current directory!
> > + cd ..
> > + /bin/pwd
> > /home/sim
> > + :
> >
> > /sbin/sh -x -c 'echo "" >foo ; pwd ; cd -@ foo ; cd .. ; pwd ; :'
> > + echo ''
> > + 1> foo
> > + pwd
> > /home/sim
> > + cd -@ foo
> > + cd ..
> > + pwd
> > /home/sim
> > + :
> >
> > Simon
> > _______________________________________________
> > ast-developers mailing list
> > [email protected]
> > http://lists.research.att.com/mailman/listinfo/ast-developers
> --
> , _ _ ,
> { \/`o;====- Olga Kryzhanovska -====;o`\/ }
> .----'-/`-/ [email protected] \-`\-'----.
> `'-..-| / http://twitter.com/fleyta \ |-..-'`
> /\/\ Solaris/BSD//C/C++ programmer /\/\
> `--` `--`
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
