From mboxrd@z Thu Jan 1 00:00:00 1970 From: forsyth@vitanuova.com To: 9fans@cse.psu.edu Subject: Re: [9fans] QID reference MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-rkxhyudeitznmevdhdleefelxw" Message-Id: <20011104191917.40FA3199B5@mail.cse.psu.edu> Date: Sun, 4 Nov 2001 19:19:56 +0000 Topicbox-Message-UUID: 13226286-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-rkxhyudeitznmevdhdleefelxw Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit it is discussed by intro(5): ... The qid represents the server's unique identification for the file being accessed: two files on the same server hierarchy are the same if and only if their qids are the same. (The client may have multiple fids pointing to a single file on a server and hence having a single qid.) The eight-byte qid fields represent two four-byte unsigned integers: first the qid path, then the qid version. The path is an integer unique among all files in the hierarchy. If a file is deleted and recreated with the same name in the same direc- tory, the old and new path components of the qids should be different. Directories always have the CHDIR bit (0x80000000) set in their qid path. The version is a ver- sion number for a file; typically, it is incremented every time the file is modified. it's quite important that Qid.path be unique for active files in the same hierarchy (identified by type and dev), otherwise bind and mount will malfunction because they ultimately depend on Qid values via the mount table. for that reason, exportfs(4) resolves qid.path clashes that can occur when it exports a hierarchy with binds and mounts within it. (the importing system will expect Qid.path to be unique in the hierarchy it sees, but the original type and dev that separated the Qid.path spaces on the exporting system are not seen on the importing system.) Qid.vers is less critical but is used by the kernel file cache for mounted file systems, and by cfs(4) and others. devices often don't maintain it; support elsewhere is a little patchy, but kfs and the file server kernel do support it, as does env(3). --upas-rkxhyudeitznmevdhdleefelxw Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for forsyth@vitanuova.com id 1004819806:10:12639:1; Sat, 03 Nov 2001 20:36:46 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1120294; 3 Nov 2001 20:36 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 27B2F19A02; Sat, 3 Nov 2001 15:36:05 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from workbench.borf.com (unknown [205.185.197.248]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 558E5199B5 for <9fans@cse.psu.edu>; Sat, 3 Nov 2001 15:35:28 -0500 (EST) To: 9fans@cse.psu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20011103203528.558E5199B5@mail.cse.psu.edu> Subject: [9fans] QID reference Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Sat, 3 Nov 2001 15:37:08 -0500 What's the idea behind the vers/path in the 9P qid? Is path just a serial number? Is there a reference to the literature? Brantley Coile --upas-rkxhyudeitznmevdhdleefelxw--