On 11/5/07, erik quanstrom <[EMAIL PROTECTED]> 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.
