Date: Thu, 14 May 2020 17:49:51 -0500 From: Kyle Evans <kevans@freebsd.org> To: "Julian H. Stacey" <jhs@berklix.com> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>, hackers@freebsd.org Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <CACNAnaGfEiagCo7f3gnL8oA%2BBxzX7YwjV=HhpuMcxvYidrZrGQ@mail.gmail.com> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> References: <CACNAnaFszg%2BQWPRS0kghsnQMxXc%2B5niPTTNiUPSmK60YyBGCzA@mail.gmail.com> <202005142017.04EKH0aA093503@fire.js.berklix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 14, 2020 at 3:17 PM Julian H. Stacey <jhs@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 ! > Sorry, this was a sloppy wording/prediction. There's no way I would have gotten to committing it before Tuesday, even, with how overcommitted I am between FreeBSD and the physical world around me. > "cat ." as been supported since Unix V6 1978 or earlier, > no problem, even occasionaly useful. > Do you have examples? The entire point of this thread is to solicit valid complaints from 'the other side.' > Most FreeBSD users wont have heard of https://reviews.freebsd.org/D24596 > (& there's only 5 other people's opinions there, apart from proposer, > & skimming through the impression is far from un-qualified approval. > > kevans@ issued arch@ just a couple days notice of intention to commit. > arch@ is also not widely read, ( I jhs@ added CC hackers@) > > Many FreeBSD end users won't even be reading hackers@ (some not > even announce@,) & would notice just yet another pointless change > sometime after upgrade. > Sure- it's hard to know just how many lists to cross-post to. Thanks for adding -hackers@. > Do not force all FreeBSD users towards gratuitous change for personal > preference for Linux behaviour. Switch to Linux, Or hack a > personalised shell on BSD that does what you want when you type > "cat ." If it's later widely popular, use it as proof to re-propose. No Rush. > Suggestions like this are wholly unwelcome. If I wanted Linux semantics, I would instead hack on Linux and ditch FreeBSD entirely. I can weave together a Linux + BSD userland if that's really what I wanted, but alas- it's not. I want sane and consistent semantics here, given that most of our filesystems either already return EISDIR or just return some garbage that maybe resembles something useful to someone (e.g. ZFS, where it's not even clear that it was intended to allow vop_read of a dir). To a degree I also want to no longer fix application bugs because they assume here the implementation-defined semantics that almost the rest of the world has already opted for (again, at least OpenBSD, MacOS, Linux). Such bugs have wasted a lot of my already sparse time because they're not always trivial to identify, and the reward for keeping this around is almost nonexistent for most users of FreeBSD, a very large chunk of which run filesystems where `cat .` doesn't produce any meaningful data. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaGfEiagCo7f3gnL8oA%2BBxzX7YwjV=HhpuMcxvYidrZrGQ>