From owner-freebsd-hackers@freebsd.org Thu May 14 22:50:03 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 40B4F2E2CAA for ; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49NRZM13Fbz43RK for ; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 222CC2E2CA8; Thu, 14 May 2020 22:50:03 +0000 (UTC) Delivered-To: hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 20C932E2CA7; Thu, 14 May 2020 22:50:03 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49NRZL75pJz43RH; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id E32DC122E6; Thu, 14 May 2020 22:50:02 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f174.google.com with SMTP id f83so603000qke.13; Thu, 14 May 2020 15:50:02 -0700 (PDT) X-Gm-Message-State: AOAM533hUdXNWDW6onAueCqLQLy1iLjAFHyZbi1vhKaOMFniPLnejoWB AVHoj/3Irci87fZGWgjXyO3lBNWbeW7g44y2sh8= X-Google-Smtp-Source: ABdhPJyfSUheNEGsNaaPEaIpnrpg2PedS3yTVInniLBJCIqGkIoYi/UZLHkGPyp5Imu2ahHT/06wpYmDW0oAHlGwNjA= X-Received: by 2002:a37:5b47:: with SMTP id p68mr738238qkb.120.1589496602347; Thu, 14 May 2020 15:50:02 -0700 (PDT) MIME-Version: 1.0 References: <202005142017.04EKH0aA093503@fire.js.berklix.net> In-Reply-To: <202005142017.04EKH0aA093503@fire.js.berklix.net> From: Kyle Evans Date: Thu, 14 May 2020 17:49:51 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [HEADSUP] Disallowing read() of a directory fd To: "Julian H. Stacey" Cc: "freebsd-arch@freebsd.org" , hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 22:50:03 -0000 On Thu, May 14, 2020 at 3:17 PM Julian H. Stacey 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