From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <85e2f17ea519dda15fa4679f40459c54@swtch.com> To: 9fans@cse.psu.edu Subject: Re: namec (was Re: [9fans] Strange date/time on some created files) From: "Russ Cox" Date: Wed, 15 Feb 2006 08:32:55 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: ff840a34-ead0-11e9-9d60-3106f5b1d025 > 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. actually, namec returns an open chan, and when the chan is opened, the Ropen includes a qid which is dutifully copied into c->qid. so if you run your example from, say, ramfs, then it just works. the bug is in fossil, which fails to update fid->qid.vers in an Ropen response. most of the time this is harmless, since the qid that is there was computed for the immediately preceding Rwalk. only when mount points get involved do walk and open messages get separated significantly. the bug is fixed on sources (/sys/src/cmd/fossil/9p.c). new binary later. russ