From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 5 Nov 2007 22:17:12 +0000 From: "roger peppe" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?) In-Reply-To: <84d7b8163cb339151fe23e621e8a29f2@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <84d7b8163cb339151fe23e621e8a29f2@quanstro.net> Topicbox-Message-UUID: eac44e86-ead2-11e9-9d60-3106f5b1d025 On 11/5/07, erik quanstrom wrote: > the qid.vers does get exported. indeed it does. but if clients aren't expected to make use of it, why *is* it exported? i guess i'm arguing that the notions of device medium version (a.k.a. nchanges) and file version are two separate things, and it doesn't really make sense to present the former as the latter. > there's another way to look at this situation. the fileservers do not > lie. they are always accurate. the client's assumptions are faulty. > ;-) no, no, that's so wrong! a fileserver is lying when it presents metadata that isn't interpretable by reading the rules set out in section 5 of the manual. the rules are sometimes bendable, as you point out, depending on who relies on them, but i think it's a good principle to try to stand behind. > this issue deserves some more thought. stat(5) says length is in bytes. > is stat(5) wrong? no, stat(5) is axiomatically right... > if we allow too much freedom in 9p, then we will not be able to > write general tools. if we don't allow enough, we will not be able to > write tools easily and succinctly. i'm not sure how much bending the rules facilitates easy and succinct tool writing. it's always tempting, but rarely worth it, i reckon, and this particular case definitely doesn't show that IMHO.