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