From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: namec (was Re: [9fans] Strange date/time on some created files) Date: Wed, 15 Feb 2006 13:04:58 +0000 From: rog@vitanuova.com In-Reply-To: <775b8d190602142229m745c406ft1c5a8aa5617e2b8a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: ff7c46be-ead0-11e9-9d60-3106f5b1d025 this conversation reminded me of a little piece of annoying behaviour under plan9. [please accept my apologies if you've seen this before - it didn't seem to get through last time] here's a demonstration: cpu% pwd /usr/rog/c cpu% > /tmp/tst cpu% cp /bin/echo 8.out cpu% bind 8.out /tmp/tst cpu% /tmp/tst -z -z cpu% cp /bin/sed 8.out cpu% /tmp/tst -z tst 424799: suicide: sys: trap: fault write addr=0x24fffbde pc=0x00017e7c the problem seems to be that attachimage() relies on sysexec() giving it a Chan with a currently valid qid.version, but when the last component of the path is translated by a mount point, namec returns the qid in the mount table's Chan, which holds a stale version number, hence the old shared text segment incorrectly used. i can think of several ways of fixing it, but all of them either slow things down slightly, or increase complexity. (for instance, one doesn't really want to do a stat when the version returned from namec *is* current, which is almost all the time).