On Fri, 16 Aug 2013 10:06:10 +0200 Cedric Blancher wrote:
> On 15 August 2013 18:54, Glenn Fowler <[email protected]> wrote:
> >
> > some questions / observations / rambling on cd -@
> >
> > on a system that has O_XATTR is there an errno for
> > open(valid_fd, O_XATTR|O_RDONLY)
> > failing because valid_fd has no extended attributes?
> If a filesystem supports NFSv4 extended attributes then all elements
> in this filesystem, including files, dirs, pipes, fifios etc support
> them.
> If a filesystem doesn't support O_XATTR it will return EINVAL, try it
> with /devices (devfs, device file system):
> ksh -c 'cd -@ /devices/pseudo'
> /home/ced/bin/ksh: cd: /devices/pseudo: [Invalid argument]
thanks
> > reason: I believe that ksh cd should always accept -@ and return
> > the errno from above, even on systems that have no O_XATTR
> You better return ENOTSUP then
right
> > I'm on a 'SunOS hostname 5.11 11.0 i86pc i386 i86pc' and
> > wanted to compare /bin/sh and /bin/bash handling of cd -@ vs ksh
> > and neither support cd -@ -- nice -- I wonder what jumbo patch has those
> > don't answer that, I'm not the solaris maintenance loop
> Bash has -@ on Solaris 11._1_ but not in 11._0_ or 10.
my surprise that /bin/sh didn't have -@
> > also, and this goes to my complaints that there is no path notation
> > for xattr dirs, when any shell /bin/bash is running from an -@ dir
> > it chokes because it can't determine pwd (other shells, ksh too, have
> > problems with that too, more on that below)
> What about returning the shp->pwdfd path, i.e.
> /proc/<pid>/fd/${shp.pwdfd}/ as physical path? Works great here:
> ksh -c 'cd -@ . ; redirect {n}<. ; cd -f $n ; pwd ; :'
> /proc/14894/fd/12
not bad but ephemeral
> > some other weirdness from an interactive session,
> > again because there is no path notation
> > --
> > $ pwd
> > /home/gsf/tst/ksh
> > $ mkdir tmp
> > $ cd -@ tmp
> > $ /bin/bash -c pwd
> > shell-init: error retrieving current directory: getcwd: cannot access
> > parent directories: No such file or directory
> > pwd: error retrieving current directory: getcwd: cannot access parent
> > directories: No such file or directory
> > $ /bin/sh -c pwd
> > pwd: cannot access parent directories [No such file or directory]
> > $ /bin/pwd
> > pwd: cannot determine current directory!
> > $ ksh -c pwd
> > pwd: cannot access parent directories [No such file or directory]
> > $ # ouch ksh bit by this too -- does olga's fgetcwd() handle this right?
> > $ pwd
> > /home/gsf/tst/ksh/tmp
> > $ ls
> > SUNWattr_ro SUNWattr_rw
> > $ cd -@ SUNWattr_ro
> > /home/gsf/arch/sol11.i386/bin/ksh: cd: SUNWattr_ro: [Not a directory]
> > $ # is that the right errno?
> > $ cd -
> > /home/gsf/tst/ksh
> > $ pwd
> > /home/gsf/tst/ksh
> > $ cd -
> > /home/gsf/tst/ksh/tmp
> > $ pwd
> > /home/gsf/tst/ksh/tmp
> > $ ls
> > $ # oops -- not in the -@ dir -- but we are in ~- # oh right, xattrs dirs
> > don't have pathnames
> > --
> >
> > so a lot of stuff going on there, most of it because -@ dirs are half-baked
> I don't think O_XATTR dirs are half-baked. They just don't have an
> anchor which is connected to / directly. It's even worse with Windows
> or OSX forks, you know? :)
mentioned in prev message, the api is half-baked because it involves re-coding
and that coding is not trivial
> > the worst I guess is that when you are in an -@ dir you can't tell
> > (or can you -- does stat(2) or some other new syscall?)
> > you get a hint when the /bin/pwd algorithm breaks, but it can break for
> > other
> > reasons that may give similar behavior
> >
> > one could argue that once you 'cd -@' you better know what you are doing
> > but I bet the /bin/bash and /bin/pwd authors thought they knew what they
> > were doing
> If think the problem is that getcwd() should return a pointer to
> /proc/22214/cwd and /bin/pwd should do the same in case they are in a
> O_XATTR dir.
> All shells, which are a system interface, surely needs support -@, or
> are boned in case they hit a directory which isn't connected to /. NFS
> can put you into the same trouble if you unlink a directory (for
> NFSv2/v3) or have it offlined under your feet (Solaris QFS, SAMFS and
> NFSv4 can do that to you).
the issue is knowing that you are in an O_XATTR dir in the first place
just discovered that O_XATTR dir inode == 0 -- this is for a default
O_XATTR dir -- once a non-default entry is added it gets a real inode
in an O_XATTR dir ".." is a hard link to the parent file
strange to see ".." listed as a regular file, but it makes sense
but its not easy retrieving the path given the inode number of a regular file
> > I belive most of these oddities, and even the need to patch /bin/sh and
> > /bin/bash and ksh,
> > could have been avoided if xattrs simply stole *something* from the path
> > namespace
> > even a (pseudo) mount point or /dev entry would work
> >
> > /dev/xattr/./tmp # . relative path
> > /dev/xattr/home/gsf/tst/ksh/tmp # absolute path
> What will happen if O_XATTR directories allow sub directories?
good question -- any path notation would have to handle that
> > this might be able to be emulated if there were an
> > is_this_an_xattr_dirat(AT_FDCWD, ".") call
> >
> > is it possible to determine if "." is an extended attr dir?
> > maybe ls gives a hint?
> >
> > $ /bin/ls -l .
> > total 2
> > -r--r--r-- 1 root root 156 Aug 15 11:15 SUNWattr_ro
> > -rw-r--r-- 1 root root 472 Aug 15 11:15 SUNWattr_rw
> > $ /bin/ls -ld .
> > drwxrwxrwt 4 gsf gsf 4 Aug 15 11:15 .
> > $ /bin/ls -@ld .
> > drwxrwxrwt 4 gsf gsf 4 Aug 15 11:15 .
> 1. -l overrides -@
> 2. -@ will only report @ if there are xattrs in the xattr dir which do
> not belong to the filesystem itself:
> ksh -c 'cd -@ . ; touch x ; ls -@ad . ..'
> drwxr-xr-x 4 ced ced 177 Aug 16 10:02 .
> drwxr-xr-x@ 2 ced ced 117 Aug 14 23:38 .
so the sole purpose of -@ is, in conjunction with -l, to display an @
after the permissions if a file has non-default extended attributes
thanks
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
