On 11/5/07, erik quanstrom <[EMAIL PROTECTED]> wrote: > 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.
i'm sorry? the server is the one *generating* the qid, surely? for instance, in the case of cdfs, the version number comes from the scsi(2) library function, and doesn't have any necessary correspondence with qid.vers as found in the data file served by cdfs. so strictly speaking, the server isn't doing any qid checking at all - it's just looking at its own data structures. > using a seperate file to detect media change introduces a > race. with network-attached media this might be a problem. there's a race anyway if you're doing the stat in a separate process. if you're not, then it's the same either way, no? > the fact is, you can't deal with a physical disk like /dev/sdE0/data > in the same way you can deal with a regular fileserver. perhaps not. but by putting device-specific information in qid.vers, you run the risk that you can't treat a file on a regular fileserver as if it was a physical disk, and i really like being able to do that. and i'm afraid i really disagree with the following: > seriously, the fewer rigid rules we make for 9p, > the more adaptable it will be. i feel that real adaptability comes from having a few, well-defined rules, and freedom within those rules. that way you get good interoperability, but also flexibility, because the rules aren't really that restrictive. for me, 9p's unwritten rule seems to be "if you do it, do it right", whether you're talking about versions, sizes, read/write offsets, or whatever. > try doing ls -lt /mail/fs/mbox. i wish this worked!
