> 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
i think you should complain to presoto or rob. it would be helpful to
do so in 1990. you may need a time machine.
while you're at it, tell ken to spell "creat" with an "e".
and you need to complain about the abuse of wstat() to imply device
i/o flushing.
☺ (just to remove any doubt)
seriously, the fewer rigid rules we make for 9p,
the more adaptable it will be.
the history migration process i built for kenfs
(/n/sources/contrib/quanstro/history.ms)
insures that for any two files on the original fs,
a.file1.qid.vers == a.file2.qid.vers =>
b.file1.qid.vers == b.file2.qid.vers.
russ thinks this is too strong an assumption in general.
i was just targeting fileservers like kenfs or fossil.
but in general, russ is correct. this wouldn't work
for devsd data files, for the reasons you mention.
> turning things around, by providing device-specific versioning behavior,
> you can end up with clients that won't work well when run over normal
> files. if a client expects the version number to change only when the
> media changes, then it's quite likely to be fairly surprised if
> the version number changes every time it writes some data.
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. clients
that make strong assumptions about ownership, dates or
qid.vers are going to get burned by devices serving up physical
media.
try doing ls -lt /mail/fs/mbox.
- erik
