From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: *** X-Spam-Status: No, score=3.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A,RCVD_IN_SBL_CSS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 4417 invoked from network); 24 Jul 2023 00:58:09 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Jul 2023 00:58:09 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Sun Jul 23 20:56:51 -0400 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1690160399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=viTyx9Jiee1FANqCAdCuOLB48TixOnCE/aJRmfUj8dU=; b=G/CulvQBY6jRZp25YXChrUsijiJicAaC+U62ki1RVbRBKx/xH+mpl7OOV3YOTQe04GsSoS oEoTKcOIOEON1u9meD6zThNaqsS7oZ0/PWQY7ujXZuWR1rC/YlwSY1NxL/MmL6IorOXyqC t1ON6MG8lHs2+TGw5Zp5P8/J3AuIlUU= Received: from [192.168.168.123] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id 71949a9a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Sun, 23 Jul 2023 19:59:58 -0500 (CDT) Message-ID: <659d1528-d809-7495-5a11-00a3a2781186@posixcafe.org> Date: Sun, 23 Jul 2023 19:56:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: 9front@9front.org References: <71ed8c49-2174-0ec5-ad59-5e1c5256fc70@posixcafe.org> From: Jacob Moody In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: lossless ISO-certified HTTP package self-signing-aware layer Subject: Re: [9front] [PATCH] make exportfs give "standard" error for file does exist Reply-To: 9front@9front.org Precedence: bulk On 7/23/23 19:07, Michael Forney wrote: > On 2023-07-23, Jacob Moody 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