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=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 3558 invoked from network); 24 Jul 2023 00:37:20 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 24 Jul 2023 00:37:20 -0000 Received: from mail-ej1-f50.google.com ([209.85.218.50]) by 9front; Sun Jul 23 20:34:26 -0400 2023 Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-992e22c09edso559298966b.2 for <9front@9front.org>; Sun, 23 Jul 2023 17:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney.org; s=google; t=1690158864; x=1690763664; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=i5JkimzK3THhez4t7enOa5PhZUq8HZcaxsvdr895pFc=; b=YY9xu6vmEiGMfvTdzS8FMGdwhaa8cjKYYBKIx8HbozbPTejMKRdo2ws+iRMkjv1ifD n2gDxOPw0I968PKVpuzmABQdquA2aqke6HoAy+Ib3KaMzIkldP1wJPKJp0CV+ftTUBGa b7evvnAnOMODrh8bs6awYmk52pO+YbpneILorQ/+K/8mMuQ7jWbJle6t1B+w/s13KLZZ syQiyWJTwcjLU0pVuQAvuj7chTMj+DPtsImQTBNAkB3+G43EGkSUKnsJc9WObIx1C9OU e56nU+PqQAnN9m+Z4s/tzBqphapa+gIfwxXsYRn/foP9Xaf2sFPQUMt0IHRqIummp8FU GdLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690158864; x=1690763664; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i5JkimzK3THhez4t7enOa5PhZUq8HZcaxsvdr895pFc=; b=YkqL3zXRW+r95VZGGMwFbAwhOwR+ChqetIuZf7M8v+S434kBPef6/0A7X6phtPdvWC Js4apq7C/WS+1sRYx8Z0TOCeiMGab5b+p+fy6Hqy2dDMFwH2T+oBSLR+7zbUKJCBjLrE sxkAfQ49XhQL147nfb5DxWLaM3izAs+cTgsqPZDDSb0lxcBgQh+/fm9PuG7i6Wu5Gb7l 2ds+xs7bQyF283Sv4KPDPCwYsT2Y4r09m0SZPtFQGVjVhLXBaM/jk4/FYzRZK1ky/uo8 mYWXtam+mpCiSRnfnkGSdHmotYiAc5GqyU3Re4nKIV4oDidYqgzfvS0VGXxYtE2RCHax HwJw== X-Gm-Message-State: ABy/qLaOxUAogbj0WY1QzxRpOV4BmHIq4xQDtOiCf8a/7eCENPXMIPxu mb561rhGmbCXmo+UVEEZ8JapXCKtw08QADdd7LgCfYybmdUi2xU9 X-Google-Smtp-Source: APBJJlFFmd4FvCep/mzXcfuIZGqsaxh0aorrOwztuFsaUnNVu9q0cJqL/6qtG05IoOb/B+te4Qp4Ayc9BpBzMUQLjlI= X-Received: by 2002:a2e:9d97:0:b0:2b4:7f2e:a433 with SMTP id c23-20020a2e9d97000000b002b47f2ea433mr4434267ljj.36.1690157276774; Sun, 23 Jul 2023 17:07:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6022:565c:b0:42:7fe8:9d40 with HTTP; Sun, 23 Jul 2023 17:07:55 -0700 (PDT) X-Originating-IP: [2601:647:6400:20b0:16dd:a9ff:fee7:6b79] In-Reply-To: <71ed8c49-2174-0ec5-ad59-5e1c5256fc70@posixcafe.org> References: <71ed8c49-2174-0ec5-ad59-5e1c5256fc70@posixcafe.org> From: Michael Forney Date: Mon, 24 Jul 2023 00:07:55 +0000 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: compliant cache YAML over AJAX replication pipelining solution Subject: Re: [9front] [PATCH] make exportfs give "standard" error for file does exist Reply-To: 9front@9front.org Precedence: bulk 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.