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?
reason: I believe that ksh cd should always accept -@ and return
the errno from above, even on systems that have no O_XATTR
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
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)
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
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
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
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 .
$ /bin/df .
df: cannot canonicalize .: No such file or directory
hmm, something else: surely my xattr dir is not world writeable, is it?
I can create and delete files in there
and the sticky bit prevents me from modifying the root files
just checked man fsattr and saw the these ast-related commands had to be
-@-ified or -xattr-ified:
cp du find ls mv pax (and they forgot cd)
$ cd -@ .
/home/gsf/arch/sol11.i386/bin/ksh: cd: .: [Invalid argument]
AHA this might be the hook:
$ cd /home/gsf/tst/ksh/tmp
$ pwd
$ ls
$ cd -@ .
/home/gsf/arch/sol11.i386/bin/ksh: cd: .: [Invalid argument]
so it looks like openat(xattrfd, O_XATTR|O_RDONLY) fails with EINVAL
for an open xattr fd
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
