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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no
	version=3.4.4
Received: (qmail 22696 invoked from network); 25 Jul 2023 06:14:29 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 25 Jul 2023 06:14:29 -0000
Received: from sendmail.purelymail.com ([34.202.193.197]) by 9front; Tue Jul 25 02:09:58 -0400 2023
DKIM-Signature: a=rsa-sha256; b=iX/Gn9bseojx+jzPNsgDqYTMLEMOr/FjO4xPv/wrmPMlMbiib8bLUIcYtBMxuaYe8HfO0B9X5Ujq6AgoHjaGkkSaoDW0W5Ewprv5bqDr9dCVy03xyCVGtC263PuQeM8+I8nk1T4lDP80+Xmn+C5WKz7/oqsaS2SzSobazeiFPafu0a7usWFOIZGMf8cNp1Fh52mTnnOeO/kj0dXje1VWv0Hv9shsy9Slzsel0N3bMTaQFvVHkZNoeXOhbdgbL550cz7S6dERcWFVU5tVDxnWuOFybm/SasyXrw4Bw25qhz5UgV99abLqIINVXVBv/KleQIZxk6uPPiNC2xudOj7Wfg==; s=purelymail3; d=pbrane.org; v=1; bh=9KqSipfOo5M8m9rcOxRNeKL5aOFLAv0qypop8xtpi28=; h=Received:From:To:Subject;
DKIM-Signature: a=rsa-sha256; b=RLtNTdTlWZlgtRHja8Toz08DZ3y4Q/dMal3Qdd7PRgXbjoXPRwQifsT9BmwWVlV3hbH0j7BWDianhEtTwsNHD2md91Mrp6XLweR1+Ng5EWYdvytLhElKnOzG5sE4EoJ5g7hHGVNE2CK6EIL6tRsrvYjqJcg8Bfg9wAuB4op8AjzhEZUI3WncHR4ZvJB/WALwHpqZlcOxng+8IyKmaTQa4UvWFmUTrb32OkZNl8SaDHfy9vwnDP0cUC/hhl2g2vuEYH9s5Zli8FIwGMTEHS/ELExjMPPSytIFCALLaCT+GKx4mK9KB/PBgdBge12Ab+YxIBrKvb3JN0XmuBM3YI43vA==; s=purelymail3; d=purelymail.com; v=1; bh=9KqSipfOo5M8m9rcOxRNeKL5aOFLAv0qypop8xtpi28=; h=Feedback-ID:Received:From:To:Subject;
Feedback-ID: 10987:2443:null:purelymail
X-Pm-Original-To: 9front@9front.org
Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1612092332
          for <9front@9front.org>
          (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
          Tue, 25 Jul 2023 06:09:49 +0000 (UTC)
Date: Mon, 24 Jul 2023 23:09:37 -0700
From: Anthony Martin <ality@pbrane.org>
To: 9front@9front.org
Message-ID: <ZL9nIWzMtS9cWNeC@alice>
References: <ZL36XiBmFhTPbgEm@alice>
 <D1E53774598794A99B1C7464953523B8@eigenstate.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D1E53774598794A99B1C7464953523B8@eigenstate.org>
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: mobile private component-aware DOM-scale XML over ORM firewall full-stack controller 
Subject: Re: [9front] Re: [PATCH] make exportfs give "standard" error for
 file does exist
Reply-To: 9front@9front.org
Precedence: bulk

ori@eigenstate.org once said:
> note, the problem with strstr is that walking to a file named
> 'file does not exist' may confuse the caller; this is why I
> would like to move to a convention where the "well known" error
> is at a well known location.

1. Spaces in file names are suspect to begin with.

2. If you name a file "file does not exist", you deserve
the consequences.

3. Almost two decades ago, ericvh wanted to standardize
error strings to appease Linux v9fs. Nothing happened.

4. Over a decade ago, rminnich proposed using "%d:%s"
with a prefixed errno for all errors, mostly to appease
Linux v9fs. Nothing happened.

5. All of this only matters because the POSIX tolerators
are trying to parse error strings to make up an "error
code" and do something special for each one so v9fs will
work with vfs_create. How can that ever not be brittle?

6. 9p2000.L, .u, etc. Enough said.

7. This is a lost cause. Outside of Plan 9, friends only
let friends use emu(1).

8. Your idea isn't bad but is it worth it?

Thanks for coming to my TED talk.

Cheers,
  Anthony