Re: [9front] [PATCH] make exportfs give "standard" error for file does exist

[ori@eigenstate.org]

Quoth Michael Forney <mforney@mforney.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.

I would be tempted to make 2 changes, and adopt a convention:

1. Replace full string comparisons with prefix comparisons
2. change 9front to add useful information as a suffix, rather than as a prefix:

	file does not exist: '/path/to/file'

this will make strncmp do the right thing, and make it possible to
both have our cake and eat it too; use well known error strings and
compare them, and still give the user additional useful information.