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.0 required=5.0 tests=none autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 31479 invoked from network); 7 Jan 2022 10:25:44 -0000
Received: from 4ess.inri.net (216.126.196.42)
  by inbox.vuxu.org with ESMTPUTF8; 7 Jan 2022 10:25:44 -0000
Received: from odoacer.turtle-trading.net ([93.241.193.16]) by 4ess; Fri Jan  7 05:10:06 -0500 2022
Received: from zenobia.turtle-trading.net ([192.168.2.111])
	by odoacer.turtle-trading.net with esmtp (Exim 4.80)
	(envelope-from <benny@turtle-trading.net>)
	id 1n5mC3-0005JW-Mj; Fri, 07 Jan 2022 11:09:55 +0100
Received: from benny by zenobia.turtle-trading.net with local (Exim 4.94.2)
	(envelope-from <benny@turtle-trading.net>)
	id 1n5mC3-001CXl-Ek; Fri, 07 Jan 2022 11:09:55 +0100
From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
To: Xiao-Yong Jin <meta.jxy@gmail.com>
Cc: 9front@9front.org
References: <8489010B86CFD46EA69165F237249F0A@eigenstate.org>
	<87lezsahx1.fsf@turtle-trading.net>
	<957691C3-81D7-4F95-975F-45E19AEBC25C@gmail.com>
Date: Fri, 07 Jan 2022 11:09:55 +0100
In-Reply-To: <957691C3-81D7-4F95-975F-45E19AEBC25C@gmail.com> (Xiao-Yong Jin's
	message of "Thu, 6 Jan 2022 14:24:27 -0600")
Message-ID: <87h7af26x8.fsf@turtle-trading.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: mobile asynchronous TOR component database browser 
Subject: Re: [9front] ape/_errno: ENOENT
Reply-To: 9front@9front.org
Precedence: bulk

Hi Jin,

Xiao-Yong Jin writes:
> Are you sure you are using the upstream 9front code?
> Because I'm getting the error string from,
> ape/lib/ap/plan9/_errno.c:77:   {ENOENT,        "directory entry not found"},

Thanks for trying it out and veryfying, that helps.

I found the problem: I am running this on a sshfs mount (to share the
source tree with the host computer).  Sshfs gets the error message from
the SSH server (OpenSSH).  Sshfs.c (/sys/src/cmd/sshfs.c:1147) prefers
the error message over the error code, and so we get Linux error
messages here instead of native ones.

I would suggest to reverse the order of those two if/else branches in
sshfs.c.  The error messages from OpenSSH so far bring no new features,
they just repeat the names of the error constants
<https://salsa.debian.org/ssh-team/openssh/-/blob/master/sftp-server.c#L518>.
The string message mechanism is still usefull as a fallback, if the
server should introduce more error messages, but for the existing
standard error codes, error messages under our own control seem more
usefull.

so long, benny