From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <3c03af7d31e57a9359d2aade038dd88b@vitanuova.com> <6382a3fce81dc84bf423fa25fca25da9@ladd.quanstro.net> Date: Mon, 15 Nov 2010 21:38:23 +0000 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9p vs http Topicbox-Message-UUID: 80aa6ae0-ead6-11e9-9d60-3106f5b1d025 On 15 November 2010 19:29, erik quanstrom wrote: >> if you mount onto one, you'll see the mounted files >> on the other. >> >> gorka was talking about identifying files from their qid. >> the version number doesn't help in identifying the file - >> someone could have modified the file 35 times between >> stats. > > what definition of "file" are you using? =C2=A0you've rejected the > definition that "file" is identified uniquely by path. i've only rejected that definition based on observation - intro(5) does state that the qid path should be unique amongst all files in the hierarchy, but that's a difficult ideal to live up to when you're multiplexing filesystems. >> anyway, even if the version number is the same, the contents >> may be different. > > i claim that a fs with this behavior would be broken. =C2=A0intro(5) > seems to agree with this claim, unless i'm misreading. you're right - fossil is broken in this respect, as is exportfs {cd /mnt/term/dev; ls -lq | sort} for a quick demo. the only correct way that i can see for a multiplexing fs to avoid this bre= akage is the keep track of every qid that it sees, allocating a new qid of its own for each one. no-one does this because it can use unbounded memory. instead they map qids on open, because relatively few files are opened. that's why i was suggesting a "big enough" qid space as another possibility. an alternative might be to remove qids from the Dir structure entirely, returning them only on walk and open.