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

[Jacob Moody <moody@mail.posixcafe.org>]

On 7/23/23 19:07, Michael Forney wrote:
> 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.

Thank you!

I agree with your conclusion of those two core issues here. I noticed that with
this error mismatch v9fs would not be able to create files. It seems to walk to the
file first to ensure that it doesn't exist before actually sending the create call.
I would argue that perhaps this is a logic error as well, and it would be better to just
send a create call. But I do know enough about posix semantics to know if there is a good
reason for this.

If you would be willing to send those patches to the linux 9p folks, I agree that would
be the best solution here. I counted that out because I have not the slightest on how
to go about that. Let me know if you need any help with that.

Thanks,
moody