Re: [9fans] bind -c[ab] -- what am I doing wrong?

[northern snowfall <dbailey27@ameritech.net>]

>
>
>well, it doesn't. what you describe is the bahaviour of the command
>according to the  man page. but here's what I observe:
>
Yeh, and what is in the man page is what happens in usage:
but only in my examples. See, this is why I shouldn't get
to check mail until I've had my cranberry juice.

This is what really seems to happen:

The first directory bound into another forces the first
to inherit the second's creation properties. Thus, when we
bind a directory of ours onto a system file, we maintain
write access.

However, when a file that we do not have write access to
is bound into a directory we do have write access to, the
permissions inherited deny creation. This is your example,
Andrey. Though, we can easily remedy this situation by
binding a writable directory over the unwritable:
    cpu% bind -ac /sys/src/cmd try
    cpu% touch try/hello
    touch: try/hello: cannot create: access permission denied
    cpu% mkdir try2
    cpu% bind -ac try2 try
    cpu% touch try/hello
    touch: try/hello: cannot create: access permission denied
    cpu% unmount try2 try
    cpu% bind -bc try2 try
    cpu% touch try/hello
    cpu% wc -l try/unmount.c
         26 try/unmount.c
    cpu%

So the chain context persists, yet is not refinfluenced
by the preemptive bind. However, this doesn't change the
state of 'try'. Its permissions are still influenced by
the first bound directory. Our perception sees creation
is allowed, and that is all we technically care about.
Though, files are generated under the second bound
directory:
    cpu% unmount try
    cpu% ls -l try/hello
    ls: try/hello: 'try/hello' does not exist
    cpu% ls -l try2/hello
    --rw-rw-r-- M 2278 snowfall snowfall 0 Jul 17 13:49 try2/hello
    cpu%

Don

http://www.7f.no-ip.com/~north_