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 6023 invoked from network); 7 Jun 2021 23:44:54 -0000
Received: from 1ess.inri.net (216.126.196.35)
  by inbox.vuxu.org with ESMTPUTF8; 7 Jun 2021 23:44:54 -0000
Received: from mimir.eigenstate.org ([206.124.132.107]) by 1ess; Mon Jun  7 19:38:10 -0400 2021
Received: from abbatoir.myfiosgateway.com (pool-74-108-56-225.nycmny.fios.verizon.net [74.108.56.225])
	by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 46adf3d4 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO)
	for <9front@9front.org>;
	Mon, 7 Jun 2021 16:37:58 -0700 (PDT)
Message-ID: <9A682C8A911A12EA44029E0FA2C19F60@eigenstate.org>
To: 9front@9front.org
Date: Mon, 07 Jun 2021 19:37:57 -0400
From: ori@eigenstate.org
In-Reply-To: <CAHtSCHK8NdHbajVDRMTXLgXRbhsBTT8JYo=gTi_9mdDMdchCWg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: rails configuration-based injection database 
Subject: Re: [9front] /proc/n/fd format clarification
Reply-To: 9front@9front.org
Precedence: bulk

Quoth binary cat <dogedoge61@gmail.com>:
> > I suspect version numbers never go up much in practice.
> 
> Sometimes they don't, but they do quite often.
> Every directory I checked had at least one file with a qid version over 9.
> /env was over 1000.
> 
>  A format that seems to have fixed width fields,
> but actually doesn't, seems like a bad idea.
> I guess it's ok for /proc/n/fd, since the first line will always be
> variable length,
> but it seems problematic for /fd/nctl.
> 
> It makes it seem like you could read data from a fixed offset instead
> of parsing the whole file,
> which will work most of the time, but will break if you open a file
> that has been edited too much.
> Imagine a script that works the first 9 times, then breaks. Not a good look.

Do you assume all integers are formatted with
exactly the required number of digits, or are
qids somehow special to you?

> What I would do is keep the qid version as decimal (for backward compatibility),
> but simply pad it enough (10 spaces) so it's fixed width, like the
> rest of the fields.
> This would mean you wouldn't have to read through the whole file to
> get the filename.
> 
> Either way, I do think the documentation should be clearer about this.

If I get a patch, I don't have objections to
applying it.