[9front] ape/_errno: ENOENT

[9front] ape/_errno: ENOENT

[Benjamin Riefenstahl]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

Tcl checks errno==ENOENT for its equivalent of "rm -f", but APE does not
recognize the errstr for that.

If somebody knows where the code for this is, we could add comment with
a pointer to that source.  Also, is there a way to find more omissions
like this?


[-- Attachment #2.1: Type: text/plain, Size: 310 bytes --]

from postmaster@4ess:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: text/x-diff
	Content-Disposition: inline;
 filename="0003-ape-_errno.c-(map)-add-another-ENOENT.patch"

[-- Attachment #2.2: 0003-ape-_errno.c-(map)-add-another-ENOENT.patch.suspect --]
[-- Type: application/octet-stream, Size: 655 bytes --]

From: Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>
Date: Sat, 25 Dec 2021 13:59:59 +0000
Subject: [PATCH] ape/_errno.c (map): add another ENOENT


Many programs check this particular errno.
---
diff dd7ad4725c5dfb26ad44e8e4206116f96f054ba4 f96fae96efebf3eb7917e2c0b55439db2b242f79
--- a/sys/src/ape/lib/ap/plan9/_errno.c	Fri Dec 10 21:47:09 2021
+++ b/sys/src/ape/lib/ap/plan9/_errno.c	Sat Dec 25 14:59:59 2021
@@ -102,6 +102,8 @@
 	{EOPNOTSUPP,	"operation not supported"},
 	{EADDRINUSE,	"address in use"},
 	{EGREG,		"unnamed error message"},
+
+	{ENOENT,	"No such file"},
 };
 
 #define NERRMAP	(sizeof(map)/sizeof(struct errmap))

-- 
1.0

Re: [9front] ape/_errno: ENOENT

[cinap_lenrek]

how's that solving anything? i can't seem to find a "No such file ..."
error to be generated from the kernel or cwfs and hjfs?

Are you seeing these messages generated from drawterm?

--
cinap

Re: [9front] ape/_errno: ENOENT

[Benjamin Riefenstahl]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

Hi cinap,

cinap writes:
> how's that solving anything? i can't seem to find a "No such file ..."
> error to be generated from the kernel or cwfs and hjfs?

I could not find it either.  I recreated the problem and it seems APE's
stat generates that error somehow.  See the attached test program
(compile with pcc).  Maybe the message is somewhere in APE, although I
could not find it in /sys/src/ape either.  If it is in APE, the errno or
the errmsg could be fixed there, of course.

Thanks, benny


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test-enoent.c --]
[-- Type: text/x-csrc, Size: 670 bytes --]

#define _POSIX_SOURCE
#define _PLAN9_SOURCE

#include <errno.h>
#include <stdio.h>
#include <sys/stat.h>
#include "/sys/src/ape/lib/ap/plan9/sys9.h"

int
main (void)
{
        struct stat attrs;
        stat("no-such-file", &attrs);
        int ecode = errno;
        char err[100];
        _ERRSTR(err, sizeof err);
        printf("errstr: %s\n", err);
        switch(ecode) {
        case ENOENT:
                printf("errno: ENOENT\n");
                break;
        case EPLAN9:
                printf("errno: EPLAN9\n");
                break;
        default:
                printf("errno: %d\n", ecode);
                break;
        }

        return 0;
}

Re: [9front] ape/_errno: ENOENT

[ori]

Quoth Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>:
> Hi cinap,
> 
> cinap writes:
> Maybe the message is somewhere in APE, although I
> could not find it in /sys/src/ape either.

./lib/ap/stdio/strerror.c:33: 	"No such file or directory",

Re: [9front] ape/_errno: ENOENT

[Benjamin Riefenstahl]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Hi ori,

> Quoth Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>:
>> Maybe the message is somewhere in APE, although I
>> could not find it in /sys/src/ape either.

ori writes:
> ./lib/ap/stdio/strerror.c:33: 	"No such file or directory",

But the actual error message is just "No such file", so some code would
have to cut the rest explicitly to get from that bit in strerror.c to
that result.

It seems that the text does actually come from the syscall, see attached
new test.  I can't find the implementation in the kernel right now,
maybe somebody has a pointer.

Thanks for any insight,
benny


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: test-enoent.c --]
[-- Type: text/x-csrc, Size: 535 bytes --]

#define _POSIX_SOURCE
#define _PLAN9_SOURCE

#include <stdio.h>

#include "/sys/src/ape/lib/ap/plan9/lib.h"
#include "/sys/src/ape/lib/ap/plan9/sys9.h"
#include "/sys/src/ape/lib/ap/plan9/dir.h"

#define DIRSIZE	(STATFIXLEN + 16 * 4)

int
main (void)
{
        char err[100] = "";
        _ERRSTR(err, sizeof err);
        unsigned char buf[sizeof(Dir) + BIT16SZ + DIRSIZE];
        int n = _STAT("no-such-file-here", buf, BIT16SZ + DIRSIZE);
        _ERRSTR(err, sizeof err);
        printf("errstr: %s\n", err);
        return 0;
}

Re: [9front] ape/_errno: ENOENT

[Xiao-Yong Jin]

> On Jan 6, 2022, at 11:32 AM, Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> wrote:
> 
> Hi ori,
> 
>> Quoth Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>:
>>> Maybe the message is somewhere in APE, although I
>>> could not find it in /sys/src/ape either.
> 
> ori writes:
>> ./lib/ap/stdio/strerror.c:33: 	"No such file or directory",
> 
> But the actual error message is just "No such file", so some code would
> have to cut the rest explicitly to get from that bit in strerror.c to
> that result.

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"},

Re: [9front] ape/_errno: ENOENT

[Benjamin Riefenstahl]

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

Re: [9front] ape/_errno: ENOENT

[有澤 健治]

Hello,

hebe% gr 'No such file' /sys/src/
/sys/src/ape/lib/ap/stdio/strerror.c:33:     "No such file or directory",
/sys/src/cmd/hg/mercurial/context.py:184:             if match.bad(fn, 
'No such file in rev ' + str(self)) and match(fn):
/sys/src/cmd/python/Doc/lib/libcommands.tex:51: (256, 'cat: /bin/junk: 
No such file or directory')
/sys/src/cmd/python/Doc/lib/liberrno.tex:28: \begin{datadesc}{ENOENT} No 
such file or directory \end{datadesc}
/sys/src/cmd/python/Modules/errnomodule.c:53: e.g. os.strerror(2) could 
return 'No such file or directory'.");
/sys/src/cmd/python/Modules/errnomodule.c:414:     inscode(d, ds, de, 
"ENOENT", ENOENT, "No such file or directory");
/sys/src/cmd/python/README:336:         No such file or directory
/sys/src/cmd/spin/pc_zpp.c:320:     {    fprintf(stdout, "spin: error, 
'%s': No such file\n", fnm);
hebe%

On 2022/01/07 2:32, Benjamin Riefenstahl wrote:
> Hi ori,
>
>> Quoth Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>:
>>> Maybe the message is somewhere in APE, although I
>>> could not find it in /sys/src/ape either.
> ori writes:
>> ./lib/ap/stdio/strerror.c:33: 	"No such file or directory",
> But the actual error message is just "No such file", so some code would
> have to cut the rest explicitly to get from that bit in strerror.c to
> that result.
>
> It seems that the text does actually come from the syscall, see attached
> new test.  I can't find the implementation in the kernel right now,
> maybe somebody has a pointer.
>
> Thanks for any insight,
> benny
>