[9front] /proc/n/fd format clarification

[9front] /proc/n/fd format clarification

[binary cat]

proc(3) lists 8 entries for each line:

>The read-only file lists the open file descriptors of the process. The first line of the file is its current directory;
>subsequent lines list, one per line, the open files, giving the decimal file descriptor number [1]; whether the file is open for
>read (r) write (w), or both (rw) [2]; the type [3], device number [4], and qid [5] of the file; its I/O unit [6] (the amount of data that may be
>transferred on the file as a contiguous piece; see iounit(2)), its I/O offset [7]; and its name at the time it was opened [8].

But this still leaves me with some questions when I look at this:

  0 r  M   68 (0000000000000001 0 00)  8192      166 /dev/cons

It seems that the qid is split into 3 parts. What are those parts?
I found this in intro(5):

          Replies (R-messages) to auth, attach, walk, open, and create
          requests convey a qid field back to the client.  The qid
          represents the server's unique identification for the file
          being accessed: two files on the same server hierarchy are
          the same if and only if their qids are the same.  (The
          client may have multiple fids pointing to a single file on a
          server and hence having a single qid.)  The thirteen-byte
          qid fields hold a one-byte type, specifying whether the file
          is a directory, append-only file, etc., and two unsigned
          integers: first the four-byte qid version, then the eight-
          byte qid path.  The path is an integer unique among all
          files in the hierarchy.  If a file is deleted and recreated
          with the same name in the same directory, the old and new
          path components of the qids should be different.  The ver-
          sion is a version number for a file; typically, it is incre-
          mented every time the file is modified.

So this mentions 3 things, a path, a version, and a type. This
checks out, until you look at the supposed lengths. The path is
supposed to be 8 bytes, which would be 16 hex digits, that's ok,
but it says 4 bytes for the version, which would be 8 hex digits,
and we don't see anything like that here. What's going on here?

-- binarycat

[9front] Re: /proc/n/fd format clarification

[Anthony Martin]

binary cat <dogedoge61@gmail.com> once said:
> So this mentions 3 things, a path, a version, and a type. This
> checks out, until you look at the supposed lengths. The path is
> supposed to be 8 bytes, which would be 16 hex digits, that's ok,
> but it says 4 bytes for the version, which would be 8 hex digits,
> and we don't see anything like that here. What's going on here?

The qid version is a decimal integer. The other
components of the qid are printed in hexadecimal.
It's just a very old convention. Note that ls(1)
with the -q flag will display the qid in the
same format.

Cheers,
  Anthony

Re: [9front] /proc/n/fd format clarification

[nicolagi]

On Sat, Jun 05, 2021 at 09:26:16AM -0400, binary cat wrote:
[snip]
> So this mentions 3 things, a path, a version, and a type. This
> checks out, until you look at the supposed lengths. The path is
> supposed to be 8 bytes, which would be 16 hex digits, that's ok,
> but it says 4 bytes for the version, which would be 8 hex digits,
> and we don't see anything like that here. What's going on here?

It's just that the version isn't written in full, leading zeros are removed.
I'm not looking at 9front right now, but devproc.c in sys/src/9/port in 4e.
Grep for procqidwidth.
(I was a bit curious so I looked this up!)
I suspect version numbers never go up much in practice.
Paths are sometimes hashes of pathnames in implementations I've seen,
they're not counters, so I guess that's why they're not trimmed.
I'll let the experts set me straight now. :-)

HTH,
Nic

Re: [9front] /proc/n/fd format clarification

[binary cat]

> 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.

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.

– binarycat

Re: [9front] /proc/n/fd format clarification

[ori]

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.

Re: [9front] /proc/n/fd format clarification

[Anthony Martin]

binary cat <dogedoge61@gmail.com> once said:
> A format that seems to have fixed width fields, but actually doesn't,
>
> [...]
>
> Either way, I do think the documentation should be clearer about this.

Fixed width fields are called out explicitly in the manuals whenever
they're used, as in draw(3),

	Each client of the device connects by opening /dev/draw/new
	and reading 12 strings, each 11 characters wide followed by
	a blank:

or acme(4),

	When read, it returns the value of the address that would
	next be read or written through the data file, formatted as
	2 decimal numbers m and n, each formatted in 11 characters
	plus a blank.

or font(6),

	Each number is right-justified and blank padded in 11 chara-
	cters, followed by a blank.

and so on. Assuming something that isn't actually written down in
the documentation is not a good idea.

> 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.

This still wouldn't work since the third field, the type, is a
single UTF-8 encoded Unicode rune which is not a fixed width.

Cheers,
  Anthony

Re: [9front] /proc/n/fd format clarification

[binary cat]

>Assuming something that isn't actually written down in
>the documentation is not a good idea.

The problem is that the actual format of the qid is undocumented (as
far as I can tell).
This is what I mean about the documentation being clearer.

>This still wouldn't work since the third field, the type, is a
>single UTF-8 encoded Unicode rune which is not a fixed width.

Well, it is not impossible to pad that with a non-printable ascii character,
but now you are possibly actually breaking stuff.
Seems like it would be best to add a few lines to the documentation,
and leave it at that.


– binarycat