9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Michael Forney <mforney@mforney.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] make exportfs give "standard" error for file does exist
Date: Mon, 24 Jul 2023 00:07:55 +0000	[thread overview]
Message-ID: <CAGw6cBvxRRQKgZy4L=UBGLN1rYui7V6aiM9YTQQ=LeE5T0i_Nw@mail.gmail.com> (raw)
In-Reply-To: <71ed8c49-2174-0ec5-ad59-5e1c5256fc70@posixcafe.org>

On 2023-07-23, Jacob Moody <moody@mail.posixcafe.org> wrote:
> Certain 9p clients *cough* Guhnew/Linucks *cough* expect a fileserver to
> give back specifically "file does not exist"
> for this certain error case. For linux specifically this results in create
> being broken. This patch catches this error
> and returns back what the broken client would like.
>
> This sucks, telling linux to go kick rocks would also be fine in my
> opinion.

I think it would be better to fix linux to better accommodate these
error messages than to add a workaround in exportfs. Or at least, we
should fix linux at the same time with the intention of reverting the
patch once the linux fix is more widespread.

The two issues at hand are:
- 9front prefixes error messages with the quoted filename in syscall
error strings, exportfs just forwards them along as Rerror, and linux
only recognizes fixed strings as errno codes. This breaks v9fs with
exportfs. If linux would strip this prefix before doing error string
to errno conversion, it would also fix strings that get mapped to
other codes, such as EEXIST.
- linux does not recognize "does not exist" as ENOENT.

I've been running the following two patches for 9p in my linux kernels
to fix these two issues respectively:

https://github.com/oasislinux/linux/commit/bcf7e4dc01ad41da7ad010fa20c517ce8edb9628.patch
https://github.com/oasislinux/linux/commit/2882844e1fbbe3c56d4ec09a8d6818636cbe1cf5.patch

Looking into this more closely, I realize that "does not exist" isn't
coming from cwfs, so the commit message in the second patch is wrong.
Do you know where "does not exist" is coming from, primarily? I don't
remember the situation I was seeing this message in. There is an
instance in /sys/src/9/port/chan.c:/^walk, which seems likely, but I'm
not familiar enough with the channel code to know when this occurs.

I can send those patches to the linux 9p maintainers. I don't think
they are too controversial, so I am optimistic that they would be
accepted, but who knows.

  parent reply	other threads:[~2023-07-24  0:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-23 21:07 Jacob Moody
2023-07-23 22:03 ` Stuart Morrow
2023-07-23 22:11   ` Jacob Moody
2023-07-23 22:24     ` Stuart Morrow
2023-07-24  0:19       ` Jacob Moody
2023-07-24 21:20         ` Stuart Morrow
2023-07-24 22:33           ` Jacob Moody
2023-07-24  0:07 ` Michael Forney [this message]
2023-07-24  0:56   ` Jacob Moody
2023-07-24  2:12   ` ori
2023-07-24  8:13     ` hiro
2023-07-24 23:37       ` Jacob Moody
2023-07-24 23:54         ` ori
2023-07-24  0:51 ` [9front] " Anthony Martin
2023-07-24  1:03   ` Jacob Moody
2023-07-24  4:13     ` Anthony Martin
2023-07-24  4:20       ` ori
2023-07-25  6:09         ` Anthony Martin
2023-07-25  8:26           ` hiro
2023-07-25 13:14           ` ori

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAGw6cBvxRRQKgZy4L=UBGLN1rYui7V6aiM9YTQQ=LeE5T0i_Nw@mail.gmail.com' \
    --to=mforney@mforney.org \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).