9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)
Date: Mon,  5 Nov 2007 18:21:52 -0500	[thread overview]
Message-ID: <25317b3da5e69c231cda29a82877f94e@quanstro.net> (raw)
In-Reply-To: <df49a7370711051417m4e243a19lefd1238748a3dfce@mail.gmail.com>

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


  reply	other threads:[~2007-11-05 23:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-05 11:18 roger peppe
2007-11-05 13:18 ` erik quanstrom
2007-11-05 14:35   ` roger peppe
2007-11-05 15:01     ` erik quanstrom
2007-11-05 16:10       ` roger peppe
2007-11-05 16:40         ` erik quanstrom
2007-11-05 17:06           ` roger peppe
2007-11-05 17:54             ` erik quanstrom
2007-11-05 22:17               ` roger peppe
2007-11-05 23:21                 ` erik quanstrom [this message]
2007-11-06  0:53                   ` Charles Forsyth
2007-11-05 17:26           ` Skip Tavakkolian
2007-11-05 18:25             ` Eric Van Hensbergen
2007-11-05 19:52               ` Skip Tavakkolian
2007-11-05 22:12                 ` Skip Tavakkolian
2007-11-05 16:42         ` erik quanstrom
2007-11-05 15:27     ` erik quanstrom

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25317b3da5e69c231cda29a82877f94e@quanstro.net \
    --to=quanstro@quanstro.net \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).