[HEADSUP] Disallowing read() of a directory fd

[Alan Somers]

On Fri, May 15, 2020 at 4:47 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Joerg Sonnenberger wrote in
> <20200515220923.GA36597 at bec.de>:
>  |On Fri, May 15, 2020 at 10:25:26PM +0200, Arne Steinkamm wrote:
>  |> On Fri, May 15, 2020 at 01:00:55PM -0700, Cy Schubert wrote:
>  |>> It's been 42 or more years since this bug was introduced. Let's \
>  |>> just fix it
>  |>> now instead of agonizing over it.
>  |>
>  |> I didn't want to add something as everything is said,
>  |> but this sentence is a little bit to provocative.
>  |>
>  |> Everything is a file describes one of the defining features of Unix.
>  |>
>  |> Calling this defining feature of Unix a bug shows to me that the ideas
>  |> behind Unix got lost in the FreeBSD universe too...
>  |
>  |Using linear storage for a directory is an implementation detail of the
>  |implementation. It's not a defining feature. "Reading" from a directory
>  |doesn't make sense for many other organisational forms. So, are you now
>  |arguing that leaky abstractions are a defining feature of Unix?
>
> In an ideal Unix world read(2)ing from a directory fd would do the
> job that getdents(2) / getdirentries(2) never moved to a standard,
> leaving us with that terrible readdir(3) stuff.  imho.
>

It's not a matter of philosophy.  A directory simply can't be mapped to a
flat file with good performance.  Directories, for instance, must support
random insertion and deletion.  Old fashioned file systems cope by
appending new directories to the end, but that necessitates linear search.
By storing directories as hash tables instead of flat files, modern file
systems like ZFS achieve good insertion, deletion, and search.  So what if
you can't list the directory's contents with read(2)?  read(2) has poor
semantics anyway.  readdir(3) is much better (though yes it has problems
with reentrancy and with NAME_MAX).

-Alan