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

[erik quanstrom <quanstro@quanstro.net>]

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

i think something's lost in the translation here.

the client is not responsible for checking the qid.version.  the
server (e.g. devsd, devaoe or devfloppy) does the qid checking
itself.  the server checks if the chan.qid.vers != data.vers then
issue Echange.

i don't see the utilitiy in incrementing the vers on write.

using a seperate file to detect media change introduces a
race.  with network-attached media this might be a problem.

- erik