Date: Fri, 15 May 2020 13:48:05 +0200 From: Guido Falsi <mad@madpilot.net> To: =?UTF-8?Q?Stefan_E=c3=9fer?= <se@freebsd.org>, Arne Steinkamm <arne@Steinkamm.COM> Cc: freebsd-arch@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: [HEADSUP] Disallowing read() of a directory fd Message-ID: <f3567dc6-b3ee-7495-eef7-010f5abab6cf@madpilot.net> In-Reply-To: <e5a21dd4-6c53-2dca-8fa8-387e2532b7c8@freebsd.org> References: <CACNAnaFszg%2BQWPRS0kghsnQMxXc%2B5niPTTNiUPSmK60YyBGCzA@mail.gmail.com> <202005142017.04EKH0aA093503@fire.js.berklix.net> <CAOtMX2i2Z-KX=3rYR2nZ1g1Lb_tF==H3xPKcQMBxJs1Kqr-meQ@mail.gmail.com> <20200514203030.GT82984@trajan.stk.cx> <20200515011258.GW82984@trajan.stk.cx> <e5a21dd4-6c53-2dca-8fa8-387e2532b7c8@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15/05/20 11:47, Stefan Eßer wrote: > Am 15.05.20 um 03:12 schrieb 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@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. > > And how many shell scripts will break if you migrate from UFS to ZFS > which does not return the same data? > > Reading a directory entry as a byte stream for low level debugging has > been the only valid use case I've seen in this thread. > > And I'm convinced that any developer going to work on that part of UFS > would consider adding debug code to provide or display that information > (or remove the error return just for local testing) a minor annoyance. > >> But I know for sure that there is no need to make this change. >> Not 1976, not 2020 nor in the future. > > There might be no need in the strict sense, but some reasons have been > provided: > > - Linux, macOS, OpenBSD do it (not a good reason in itself) > > - applications developed with Linux or macOS in mind might expect it > (and that is a valid reason, IMHO) Chiming in just to note that this is not a theoretical thing, I stumbled upon such a problem of this a little time ago: https://github.com/yarnpkg/yarn/issues/4884 -- Guido Falsi <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f3567dc6-b3ee-7495-eef7-010f5abab6cf>