> That is it doesn't compare only the qid.path, so in my > syntetic file server I can differentiate between files > by using a unique-to-me qid.type and then using qid.path > to hold the index of my files in a table?
qid.type is defined to be the top 8 bits of the mode so unless you meant QTDIR vs QTFILE, the value can't sensibly be used by the server. in simple cases, the path is just an index, selecting file-specific (meta)data, which could include the server-specific file type. in multiplexors, commonly a few bits of the path give a file type (eg, ctl, data etc) and (many) more bits give the conversation number. >however I do rembember somthing about an agregating server >shifting the bits of clients down so they can be combined >uniquely.... i think the suggestion was that in the path (not the type), the server should try to stick to the low-order 48 bits, leaving the high-order bits available so that exportfs and others could more easily generate new paths that were (quite likely) to be unique immediately (but they'd still have to cope, if not)
