Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp28479ybm; Wed, 27 May 2020 18:13:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwH16Iw+C86n5v7ocNKzTGedul8n1XSBbWV+IODLCl5D47ylwpBVlvxlmFecUl9DsZz3A06 X-Received: by 2002:a17:907:1005:: with SMTP id ox5mr871982ejb.480.1590628411428; Wed, 27 May 2020 18:13:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590628411; cv=none; d=google.com; s=arc-20160816; b=c0lYG1zw95TmNSkUC+gq3DSR6GzBycIZs4F/Ol5pdP0c8UpGaaXiXrolGcNbyV1NNw IwJKC+al5x8wVf/jerrYFS2yVRyjxxaIVudAgHHavfMXhYTGUg7UZUEz8RdyoIX7elZM zQHV7KMR+q6tXPgWmsRTEER0Q63ZmaKDuJrcvibk+4e5ealwHxKoc5WRlInmYr7dcQLq cto3N6Sl0Wn7X4lPfvB8cg9hbuRou2PAlttxeqAoszGN19vjjQ02Svy+Nm3B7mdTeawt siiCb8CKlEGS/XHiFQLcdhLNWd3ewkQBRX9uimQ9BMeVvFQFHPAEILN9hneKs4x+JjtN 1HPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=3Usd3hItuXWzXnJRiRgIL0Mbp2Mbml3CgGvxB3mpNlo=; b=UDf+847ksbfnC4JcSOpPrAXTcS7dH8HlQm37TNAZJjT/PhCS/13NJizRgw1umYV6qE 7DAGGvA7Rrvcj5344Y2NfPTCmN3gZ/CGJsIpAznmAmhieG+QK+aux4Q+9U6f1KKzYEZe eTmi4SjfmKmPoDI4DD0U169GSrpnp/bRH6k1/ZvCQpYXhkjLwfFYj1LC/PaAiydGGzQ0 CrA++AwC2BY293YOoYzZNr6cuZ4OZ/KQvaBZPQe26bPdFFrDO6jwCt1SrgAbJT/8COyy UGTR2iD2xB23uqcDGem2E6Eyg2LR0lq7oYV0E2xmgaIznZ03w8azkfP+k68eyLQhG5Ky jNdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly19si545683ejb.394.2020.05.27.18.12.53; Wed, 27 May 2020 18:13:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725747AbgE1BM0 (ORCPT + 99 others); Wed, 27 May 2020 21:12:26 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:59460 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725294AbgE1BM0 (ORCPT ); Wed, 27 May 2020 21:12:26 -0400 Received: from callcc.thunk.org (pool-100-0-195-244.bstnma.fios.verizon.net [100.0.195.244]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04S1CLnC022045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 May 2020 21:12:21 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 15279420304; Wed, 27 May 2020 21:12:21 -0400 (EDT) Date: Wed, 27 May 2020 21:12:21 -0400 From: "Theodore Y. Ts'o" To: Jonny Grant Cc: linux-ext4@vger.kernel.org Subject: Re: /fs/ext4/namei.c ext4_find_dest_de() Message-ID: <20200528011221.GC228632@mit.edu> References: <2edc7d6a-289e-57ad-baf1-477dc240474d@jguk.org> <20200504015122.GB404484@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Wed, May 27, 2020 at 10:25:43PM +0100, Jonny Grant wrote: > > > How about adding an improved mkdir to POSIX and the Linux kernel? Let's call it mkdir2() > > It has one more error, for EISDIR > > [EEXIST] > The named file exists. > > [EISDIR] > Directory with that name exists. It's *really* not worth it. You seem to really care about this; why don't you just keep your own version of shellutils which calls stat(1) if you get EEXIST and to distinguish between these two cases? I know the shellutils maintainers has rejected this. But that's OK, you can have your own copy on your systems. You might want to reflect that if the shellutils maintainer refused to add the stat(1) on the error path, what makes you think they will accept a change to use a non-standard mkdir2() system call? If you want to try to convince Austin Common Standards Revision Group that it's worth it to mandate a whole new system call *just* for a new error code, you're welcome to try. I suspect you will not get a good reception, and even if you did, Linux VFS maintainer may well very well deride the proposal as silly, and refuse to follow the lead of the Austin group. In fact, Al Viro is very likely not to be as politic as I have been. (It's likely the response would have included things like "idiotic idea" and "stupid".) > I'm tempted to suggest this new function mkdir2() returns 0 on success, or > an error number directly number. That would do away with 'errno' for this as > well. This is not going to get a good reception from either Al or the Austin Group, I predict. If you really have strong ideas of what you think an OS and its interfaces should look like, perhaps you should just design your own OS from scratch. Best regards, - Ted