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?
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
