9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jacob Moody <moody@posixcafe.org>
To: Alyssa M via 9fans <9fans@9fans.net>
Subject: Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
Date: Thu, 22 Feb 2024 14:27:39 -0600	[thread overview]
Message-ID: <4f3c46d8-d10e-4bf4-a6f8-376ee11bb0c0@posixcafe.org> (raw)
In-Reply-To: <17086311280.67fcAA.82492@composer.9fans.topicbox.com>

I apologize I had recalled incorrectly in my previous email on this topic.
We had intentions of fixing this issue with v9fs but only half of the work
was done. 9front changed that specific error in the kernel to suffix the
filename instead of prefix the filename to

A) be more consistent with userspace
B) allow use of strncmp() with the error

The intention was to submit a patch to Linux to change their memcmp()
to use strncmp() to allow this to be recognized. If I recall mcf had
intended to submit said patch but I am unaware of where that went.

In the meantime a hack around in exportfs is probably the best option.

In regards to hjfs, I agree it should probably be brought in line with
this if this is the convention we would like v9fs to use. I will purpose
a patch to change it on the 9front list.

Apologies and thank you,

On 2/22/24 13:45, Alyssa M via 9fans wrote:
> 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 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 could 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 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 ENOENT it won't attempt the subsequent create message.
> v9fs currently does an exact match on the error string returned in Rerror and 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.
> 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 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 problems:
> The first and most obvious one is that v9fs doesn't cope well with the variety 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 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 the entries in that file can actually pattern-match any embedded quoted filename, allowing for future creativity in the ways it can get inserted into the error string returned via Rerror...
> I'm not sure I quite believe I'm seriously contemplating doing this.
> Perhaps I'm missing something obvious.
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M73bf1acd981988335f610ae6>

9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mee427615742065db50311a27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  reply	other threads:[~2024-02-22 20:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-04 15:07 [9fans] " Alyssa M via 9fans
2024-02-04 16:41 ` [9fans] " moody
2024-02-04 16:50   ` Alyssa M via 9fans
2024-02-04 22:19     ` Alyssa M via 9fans
2024-02-22 19:45       ` Alyssa M via 9fans
2024-02-22 20:27         ` Jacob Moody [this message]
2024-02-23 12:12           ` Alyssa M via 9fans
2024-02-23 18:18             ` Jacob Moody
2024-02-25  1:01               ` Alyssa M via 9fans
2024-02-23  8:03         ` Lucio De Re
2024-02-04 16:46 ` moody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4f3c46d8-d10e-4bf4-a6f8-376ee11bb0c0@posixcafe.org \
    --to=moody@posixcafe.org \
    --cc=9fans@9fans.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).