From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob21.topicbox.com (tb-ob21.topicbox.com [173.228.157.67]) by inbox.vuxu.org (Postfix) with ESMTP id 3F340236C8 for ; Thu, 22 Feb 2024 20:45:38 +0100 (CET) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob21.topicbox.com (Postfix) with ESMTP id DCC6032516 for ; Thu, 22 Feb 2024 14:45:35 -0500 (EST) (envelope-from bounce.mM73bf1acd981988335f610ae6.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id B74EAF592DA; Thu, 22 Feb 2024 14:45:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to :message-id:in-reply-to:references:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:subject:from :list-unsubscribe; s=dkim-1; t=1708631135; x=1708717535; bh=q93L KvU7ChwaaWZiIWP7L8NjqThHRFxqKrUh1tY4GaY=; b=U8B2R8TcXoHv4uSiLPIK 1uHSb1IPmQfC1HVK+bJXmxAZV2dRJH29oCkbDwSmgTr0YPshdeXX5jpl2jZ+bTnk PzHs+8ZhU+XyDaXwDplw6/R4ZO8du5jXHtVR0KD+LMe8kc3I5+pohsedl6IT96Uw JxvGki5Ds89lkk62ZuF/Xt4= To: 9fans <9fans@9fans.net> Message-Id: <17086311280.67fcAA.82492@composer.9fans.topicbox.com> In-Reply-To: <17070851850.5D4Acd.328289@composer.9fans.topicbox.com> References: <17070592670.E7CF6327b.7700@composer.9fans.topicbox.com> <17070649110.Bb83425E.69346@composer.9fans.topicbox.com> <17070654320.9a2dd3.8938@composer.9fans.topicbox.com> <17070851850.5D4Acd.328289@composer.9fans.topicbox.com> Date: Thu, 22 Feb 2024 14:45:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17086311281.cC24.82492 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: ee7985cc-d1ba-11ee-bf97-34f640decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UYmM3OGQyOWFiMDQ2NTJhMi1NNzNiZjFhY2Q5ODE5ODgzMzVmNjEw?= =?UTF-8?B?YWU2Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Subject: [9fans] Re: Hello, RPi fixes and bind -b trouble From: "Alyssa M via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M73bf1acd981988335f610ae6:1:CeYxVYghbedcAroVjmWSNjIL9iHkdVo6_DSmaW1IWBg --17086311281.cC24.82492 Date: Thu, 22 Feb 2024 14:45:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, my daughter has kindly given me a couple of her spare raspberry pis -= a pi4 and a pi5. I've put 9front on the pi4, and have been having a look at it. I had to use= the Raspberry Pi Imager program this time. windd didn't work (she thinks t= his might be a feature of the later Pis). There are 5 computers on my desk = now! :) I'm running out of room for my teacup. I have a 2-port kvm, and I c= ould be using drawterm for the Plan 9 installations, but if I do that I won= 't be motivated to finish implementing a drawterm for my own system... I tried mounting a 9front exportfs on Linux, but encountered the same probl= em I mentioned earlier: the error strings don't match what v9fs on Linux is= expecting, with effect that I can't create files from Linux on a file syst= em exported from 9front either. I think the problem is that v9fs tries to o= pen a file before creating it: if it doesn't get an error that it can recog= nise as corresponding to ENOENT it won't attempt the subsequent create mess= age. v9fs currently does an exact match on the error string returned in Rerror a= nd will recognise any of the following strings: "No such file or directory" "directory entry not found" "file does not exist" "file not found" "illegal path element" "directory entry is not allocated" as being different ways of saying ENOENT (which has the numeric value of 2)= . It looks like the 4th Edition kernel prefixes these with the filename in = quotes, e.g.: "'foo' file does not exist" I spoke earlier about my patch to exportfs(4) to get around this.=20 On 9front, though, I'm seeing: "not found: 'foo'" or "file does not exist: 'foo'" depending on which file system is involved. Even if I apply my exportfs pat= ch to 9front, it looks like hjfs(1) has introduced "not found" as a=C2=A0 n= ew way to say "file does not exist", and v9fs is not going to understand th= at either... I suppose I could add a special case in exportfs to translate = that into "file not found". I see several problems:=20 The first and most obvious one is that v9fs doesn't cope well with the vari= ety of ways ENOENT gets encoded over 9p. The second is that there seems to = be an assumption that: a) errors are only ever immediately reported to the user, and b) the user speaks English... For me, I have a very analogous problem with the 9p client file system adap= ter on my own OS: I'm thinking at this point that I'm going to have to extract the currently = fixed strings it recognises into a file (which I can edit to keep up with t= he times) and also use regular expressions so that the entries in that file= can actually pattern-match any embedded quoted filename, allowing for futu= re creativity in the ways it can get inserted into the error string returne= d via Rerror... I'm not sure I quite believe I'm seriously contemplating doing this. Perhaps I'm missing something obvious. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M73bf1= acd981988335f610ae6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17086311281.cC24.82492 Date: Thu, 22 Feb 2024 14:45:28 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, my daughter has kindly given me a couple= of her spare raspberry pis - a pi4 and a pi5.
I've put= 9front on the pi4, and have been having a look at it. I had to use the Ras= pberry Pi Imager program this time. windd didn't work (she thinks this = might be a feature of the later Pis). There are 5 computers on my desk now!= :) I'm running out of room for my teacup. I have a 2-port kvm, and I c= ould be using drawterm for the Plan 9 installations, but if I do that I won= 't be motivated to finish implementing a drawterm for my own system...<= br />

I tried mounting a 9front exportfs on Linu= x, but encountered the same problem I mentioned earlier: the error strings = don't match what v9fs on Linux is expecting, with effect that I can'= ;t create files from Linux on a file system exported from 9front either. I = think the problem is that v9fs tries to open a file before creating it: if = it doesn't get an error that it can recognise as corresponding to ENOEN= T it won't attempt the subsequent create message.
v9fs = currently does an exact match on the error string returned in Rerror and wi= ll recognise any of the following strings:

"No such file or directory"
"directory entr= y not found"
"file does not exist"
"file not found"
"illegal path elemen= t"
"directory entry is not allocated"
<= /div>

as being different ways of saying ENOENT (which = has the numeric value of 2). It looks like the 4th Edition kernel prefixes = these with the filename in quotes, e.g.:

&= quot;'foo' file does not exist"

I spoke earlier about my patch to exportfs(4) to get around this.
=
On 9front, though, I'm seeing:

<= div>"not found: 'foo'"

o= r

"file does not exist: 'foo'= "

depending on which file system is i= nvolved. Even if I apply my exportfs patch to 9front, it looks like hjfs(1)= has introduced "not found" as a  new way to say "file = does not exist", and v9fs is not going to understand that either... I = suppose I could add a special case in exportfs to translate that into "= ;file not found".

I see several probl= ems:
The first and most obvious one is that v9fs doesn'= ;t cope well with the variety of ways ENOENT gets encoded over 9p. The seco= nd is that there seems to be an assumption that:
a) errors = are only ever immediately reported to the user, and
b) the = user speaks English...

For me, I have a ve= ry analogous problem with the 9p client file system adapter on my own OS:
I'm thinking at this point that I'm going to have to= extract the currently fixed strings it recognises into a file (which I can= edit to keep up with the times) and also use regular expressions so that t= he entries in that file can actually pattern-match any embedded quoted file= name, allowing for future creativity in the ways it can get inserted into t= he error string returned via Rerror...
I'm not sure I q= uite believe I'm seriously contemplating doing this.
Perhaps I'm missing something obvious.
<= br />
= --17086311281.cC24.82492--