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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13147 invoked from network); 5 Jun 2021 14:26:22 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 5 Jun 2021 14:26:22 -0000 Received: from mail-ed1-f42.google.com ([209.85.208.42]) by 1ess; Sat Jun 5 10:19:50 -0400 2021 Received: by mail-ed1-f42.google.com with SMTP id i13so14506408edb.9 for <9front@9front.org>; Sat, 05 Jun 2021 07:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=UP16EyALvCAxpgNkenwlGXE5QvpZAaPb7zrbExT/ZA0=; b=FLynoVnvQIwfuiBlhXazbFE62FSs0rC3PeCDwOPLQWQEzGGbIN9X2mcsilWs2F4g+b yaMO3uYnMt2OkDB2BuKcSs6GQH59x4dxh7w5A2OYRF14GkWWsUbSwxhBy8cE9xYgrMUD A19XE0y6QkVVMaD8DFZ/Z5B7ICQLYXaTusTHdCoguWf9KGlATV7DhTMen/2zrE8JxIgw KkkMlGY4hI2TDn9KlyhF9FnSy2K9I2ZhytJyaVQgcaszFviD081EHZ0ME6LpMRzPvPvt F4kR+AemYMrTox9C+YwOyhW5Nlt5syGrEhd2mTXnh1MdGoKx90ONw4D3j7X0XVFZltR9 ON5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UP16EyALvCAxpgNkenwlGXE5QvpZAaPb7zrbExT/ZA0=; b=bWFqV0PK+GoriUxrY4LREnCtx9PqJVOk4sBFA2AJ4MM4S/zFQ7NLxO8yAvYyJ1Jq8Q 7OGTZP1nPYjYM68iXhniKIQwyhmXerm98YO+qgE7yp3eWFMXncUUJULMfAGXIA7m59Lv FUK4RinTEK7zz6cOAn5eQZDWlpvRVxT02i181dd9aAvtS44QcEjNCJRmuqcpqlu/vw71 q4ZGq/1kIQswl4+MIVa1L1Oazbsj2QVsRzUqwTbsrT+gI7JpifnaQkhK8pW3S7vdBONL NA01t2xMGpawPwY4fTWpA+Cl9R3uhyMQWN0mjD2zfET2kJDKtqfKWuShQvCSlvtdrymx Wqzg== X-Gm-Message-State: AOAM533xUC9LK6MxexmBUxsATy3E0t2L2cHaOHhUN/3Wktzxui02286Q kWIBcf/Mk3dBy789PWa9rr3jaH3YfUsuwzxxt5sDvKKwI3MLXA== X-Google-Smtp-Source: ABdhPJzhlyhOi9j17D0j8Gn9Cv7gEGFl+hEXdX6pHEXFxt4zneztAPTKuJ+jwWfH+QX1vUONDATu1T/0MRWJb5ntKd8= X-Received: by 2002:a05:6402:3134:: with SMTP id dd20mr8912527edb.59.1622899595041; Sat, 05 Jun 2021 06:26:35 -0700 (PDT) MIME-Version: 1.0 From: binary cat Date: Sat, 5 Jun 2021 09:26:16 -0400 Message-ID: To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: information extension reduce/map layer Subject: [9front] /proc/n/fd format clarification Reply-To: 9front@9front.org Precedence: bulk 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