Re: device-specific qid.version behaviour (was Re: [9fans] QTCTL?)

["roger peppe" <rogpeppe@gmail.com>]

On 11/5/07, erik quanstrom <quanstro@quanstro.net> wrote:
> i still don't agree that this is anomolous behavior.  when the medium
> has changed, the file has changed.  it has a new set, and possibly a different
> number of blocks.  this is exactly the case where ken's fs or fossil
> assign a new qid.vers.

i agree it's perfectly reasonable to assign a new qid.vers in this case.
but if it's going to do this, i think it should also assign a new qid.vers
when the data file has been written to.

> further, this behavior only holds for /dev/sdXX/data and a few other files, like
> /dev/fd?^(diskc ctl).  i don't see how this could break anything.
> could you give a senario that would be broken in this case?
> i can't find any programs that use the qid.version for anything except
> to infer that a file has changed if it qid.vers has changed.

i gave one scenario. to expand on it: say dossrv expected this behaviour.
it would then do an occasional stat; if the qid.vers had changed, it
would assume that the floppy had been swapped and abort with an error.
this would mean that i could no longer use dossrv on a conventional
file, because every time dossrv wrote to the file, it would then
abort, thinking that the floppy had been swapped because the version
number had changed.

as it happens, neither dossrv, nor 9660srv do check the version
number this way, as far as i can see (even though 9660srv could, without loss
of generality)

> by the way, your claim that this is new behavior is not correct.
> russ' plan9history shows that the floppy driver use the qid.vers in
> this way on 1991/0925.
>         http://swtch.com/cgi-bin/plan9history.cgi?f=pc/devfloppy.c;v=history

um, i don't think i said that it was new behaviour. i did say that i thought it
was an abuse of the semantics, and i still think so. to me the devfloppy
code you point to looks like it was just using the Chan as a
convenient place to store
the version, rather than to deliberately make the information
available publicly.
i'm probably wrong about that, but i don't think it makes a good precedent.
i still think that having a separate file representing the medium itself,
rather than the data contained within it, would be a better solution.