ikrabbe / plan9front

Automatically exported from code.google.com/p/plan9front
0 stars 0 forks source link

bind new old -> affects new #228

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
referring to 'bind new old' as in bind(1), i'm finding new is affected as well 
as old. i first noticed it when a mk install failed with 'permission denied' 
when BIN=$home/bin/$cputype/aux . (cputype=amd64 in this case.) 

i ran 'ls -ld $home/bin/amd64/aux' and all seemed in order; it was owned by 
ethan with mode 775. i then listed it without -d: 'ls -l $home/bin/amd64/aux' 
and was surprised to find every binary from /amd64/bin/aux appear in the list. 
i don't bind anything over /usr/ethan/bin/*, the dirs there are only used as 
the 'new' parameter to bind commands, so why are they affected?

here are the binds i have:
http://ethan.uk.to/static/tmp/funky-binds
you can also see $home/bin/amd64/aux is missing from ns although it should have 
been set up in the first for loop in $home/lib/profile. i only set this up a 
few days ago, it's the first time i've set up anything like recursive binds. 

my kernel was built on either nov 8 or dec 4. i think it's the latter, but 
can't be sure.

today i found a much simpler case which affects my modified rio. (i'll test 
with unmodified rio soon.) 'bind /dev/null /dev/label' results in reads of 
/dev/wsys/*/^(label text) all returning nothing as if all these had /dev/null 
bound over them.

Original issue reported on code.google.com by tereniao...@gmail.com on 5 Dec 2014 at 9:33

GoogleCodeExporter commented 9 years ago
binds and mounts match on moundid,qid, not the path. not a bug, just confusion.

Original comment by cinap_le...@felloff.net on 8 Dec 2014 at 1:19