From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Michael Subject: Re: [PATCH shepherd] support: Ignore errors on parent directories in mkdir-p. Date: Fri, 5 Feb 2016 13:22:48 -0500 Message-ID: References: <8760y7axn2.fsf@gmail.com> <87d1scbeyc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42495) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRl1u-0003qb-FW for guix-devel@gnu.org; Fri, 05 Feb 2016 13:22:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRl1t-00042e-Ez for guix-devel@gnu.org; Fri, 05 Feb 2016 13:22:50 -0500 In-Reply-To: <87d1scbeyc.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel@gnu.org On Thu, Feb 4, 2016 at 11:47 AM, Ludovic Court=C3=A8s wrote: > David Michael skribis: > >> My use case for this is that I have a crazy Hurd setup that boots a >> read-only root file system with a passive tmpfs translator on /run. >> When mkdir-p runs with "/run/shepherd", it tries to mkdir "/run". On >> Hurd, mkdir first tests for a read-only file system, so mkdir-p catches >> and throws EROFS instead of catching and ignoring EEXIST. The init >> process then dies when it tries to stat the non-existent /run/shepherd. >> >> This patch ignores all errors from parent directories, assuming we only >> really care about the status of creating the final path component. >> >> Another possibility could be to try to change Hurd's error ordering >> instead, but it seems to be acceptably standard behavior: >> >> If more than one error occurs in processing a function call, any one >> of the possible errors may be returned, as the order of detection is >> undefined.[0] > > Interesting! > > I think that it=E2=80=99s a case where it would be beneficial for the Hur= d to > follow what Linux does, which is to return EEXIST. > > How does Coreutils=E2=80=99 =E2=80=98mkdir -p=E2=80=99 behave in this sit= uation? (I=E2=80=99ve looked > at mkdir-p.c in Gnulib but it=E2=80=99s a bit complicated=E2=80=A6) After a quick glance it basically looks like after any error occurs from a mkdir call, it tests if the path exists and is a directory, and if so, proceeds ignoring that mkdir error. If mkdir fails and the directory doesn't exist afterwards, then the mkdir-p call fails with that error. That sounds like the best option to me: keeping mkdir-p independent of the mkdir implementation, while preserving the error from the first real problem it encounters. I'll send a patch with that change instead. If you'd still prefer to change the Hurd behavior, we could copy the bug-hurd list to discuss, since I'm not sure if such a change will have unintended consequences elsewhere. Thanks. David