Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3956428ybz; Mon, 4 May 2020 12:55:48 -0700 (PDT) X-Google-Smtp-Source: APiQypIkDRPuNt2Ln0sp/EJhkCjLeDhb0/fbqSFi2+IuzBiE1EiqFOSLQ0sqNjzWti5fQ75O+Q+r X-Received: by 2002:a50:9e8f:: with SMTP id a15mr15692088edf.68.1588622148571; Mon, 04 May 2020 12:55:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588622148; cv=none; d=google.com; s=arc-20160816; b=WNawbnBAVCju02vzQfbOX3Sqwppgc8GGmGQKk2lXZmHCRniU9RB0ytW2r8LgeyGtPk JRBVSnePkDYqo9gD+yVRdR9ppji4MbvhTzE/BIB/lcSyaacHNJqZuYzhERRuxvq0u5c4 d24rqXu9hjm9T9lXLuQWqqfGFerHAlm5vS3fmQh/fPnJ6wpW59D+3DLG2QGIG0Yq76uw dDB646wEwd8ONi2ZmM5mCIHaGJJNBHZj5PZUpNPZU5JhafMLHNBuYzfuSZ0SYp7pMqLO s+D29WXBMn6KU+rpchGGYdKpIVbqEQtNLNXD+wAFCRcNdIkHw/LOFzLQepyo8a3/Zu09 5SiQ== 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=TzE4557vg4z10MWOaDAdw9v5sNUWI1sIJIQtswQJbXA=; b=g2ews/7JA3LpfG64j2AsZrfv3IZyKf2YP+qob7G2oKWrjgKTOn2i7/h5z23og55KD+ qHpqV1NF5NDLT8BBvvSlqYRgB8aYTstX5aPPnqDQpVsP5JVbV6eLhM9+Qh41wjF3wbh5 skT7hk3Aem6noe1i7UK5hb1ZFm5xN4uwlciYXhKWlU1drnhU5BDKGO8acFnm5oeAgVEP bOKAUkxCKHwN94Wy5bZDZskNV4D/05cS7Gzj39p52SAKJkxHKj+t9dzB2/5bmoZ38OGr liPpEWdpmmUqnNbZOdg+N2SFMALL2/uC4c32zTqhlGIX30H0cCE19cIRACx+0laxE60C 2P2Q== 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 rv10si7388198ejb.519.2020.05.04.12.55.17; Mon, 04 May 2020 12:55:48 -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 S1726338AbgEDTxA (ORCPT + 99 others); Mon, 4 May 2020 15:53:00 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:48295 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726111AbgEDTxA (ORCPT ); Mon, 4 May 2020 15:53:00 -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 044JqteM014042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 May 2020 15:52:56 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id AE03D42085D; Mon, 4 May 2020 15:52:55 -0400 (EDT) Date: Mon, 4 May 2020 15:52:55 -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: <20200504195255.GC404484@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 Mon, May 04, 2020 at 08:38:33AM +0100, Jonny Grant wrote: > > > I noticed that mkdir() returns EEXIST if a directory already exists. > > > strerror(EEXIST) text is "File exists" > > > > > > Can ext4_find_dest_de() be amended to return EISDIR if a directory already > > > exists? This will make the error message clearer. > > > > No; this will confuse potentially a large number of existing programs. > > Also, the current behavior is required by POSIx and the Single Unix > > Specification standards. > > > > https://pubs.opengroup.org/onlinepubs/009695399/ > > > Is it likely POSIX would introduce this change? It's a shame we're still > constrained by old standards (SVr4, BSD), but it's fine if they can be > updated. No, because it has the potential to break existing Unix/Linux/Posix-compliant programs. There may very well be C programs doing the following.... if (mkdir(filename) < 0) { if (errno != EEXIST) { perror(filename); exit(1); } } For example, there may very well be implementations of "mkdir -p" that do precisely this. If we change the error returned by the mkdir system call as you propose, it would break these innocent, unsuspecting programs. That's not something which will be allowed, because it falls into the category of a Bad Thing. Best regards, - Ted