From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <25317b3da5e69c231cda29a82877f94e@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon,  5 Nov 2007 18:21:52 -0500
In-Reply-To: <df49a7370711051417m4e243a19lefd1238748a3dfce@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: eae36b7c-ead2-11e9-9d60-3106f5b1d025

>> 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.

why supress it?  it might be useful to some applications to notice
media change and act without needing to do i/o.

>> 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...

who made that rule?  if you believe that, you might want to submit a
number of patches against the plan 9 kernel since it's clearly wrong.

>> 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.

really?  so you're writing to a cd and you forget about it.  you're
between sessions when you swap cds.  /dev/sdXX should
a)  allow you to continue writing, wrecking the second cd, or
b)  give you an error.
or, you've read a directory on a floppy.  somebody swaps the flop.
you want
a)  to get the old information
b)  for dosfs to get wacked over the head so it rereads everything.

if you choose b), you need devsd to act like it does.

- erik