[HEADSUP] Disallowing read() of a directory fd

[Arne Steinkamm]

On Thu, May 14, 2020 at 02:20:45PM -0600, Alan Somers wrote:
> On Thu, May 14, 2020 at 2:17 PM Julian H. Stacey <jhs at berklix.com> wrote:
> 
> > Kyle Evans wrote:
> > > Hi,
> > >
> > > This is a heads up, given that I'm completely flipping our historical
> > > behavior- I intend to commit this review in a couple days' time
> > > without substantial objection: https://reviews.freebsd.org/D24596
> > >
> > > With this, FreeBSD 13 will not allow read() of a directory fd, which
> > > could have previously returned some data from the underlying
> > > filesystem in no particular standardized format.
> > >
> > > This is a still-standards-compliant switch from one
> > > implementation-defined behavior to another that's already been adopted
> > > in various other popular kernels, to include OpenBSD, MacOS, and
> > > Linux.
> > >
> > > Worth noting is that there's not really one largely-compelling reasons
> > > to switch this after so many years (unless you find yourself that
> > > irate when you accidentally `cat` a directory), but there are some
> > > benefits which are briefly discussed in the commentary around the
> > > review along with the history of the current behavior.
> > >
> > > This change also simplifies filesystem implementations to some extent.
> > >
> > > Thanks,
> > >
> > > Kyle Evans
> >
> > There is ZERO need for a spurious change at 2 days notice after 42+ years !
> >
> > "cat ." as been supported since Unix V6 1978 or earlier,
> > no problem, even occasionaly useful.
> >
> 
> Really?  When is that occasionally useful?  I've never seen anything useful
> come out of reading a directory.

It's all about files in Unix...

This is true since 1972.

And files can be read!

How many (bad programmed) shell scripts will break when directory files can't
be read anymore? I have no idea.

But I know for sure that there is no need to make this change.
Not 1976, not 2020 nor in the future.

.//. Arne

-- 
Arne Steinkamm         | Home:     Mail: arne<at>steinkamm<dot>com