Re: [PATCH shepherd] support: Ignore errors on parent directories in mkdir-p.

[Ludovic Courtès]

David Michael <address@hidden> 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’s a case where it would be beneficial for the Hurd to
follow what Linux does, which is to return EEXIST.

How does Coreutils’ ‘mkdir -p’ behave in this situation?  (I’ve looked
at mkdir-p.c in Gnulib but it’s a bit complicated…)

> Can this be applied, or do you prefer another option?

I would prefer not to hide the initial error like the proposed patch
does.

OTOH, it’s no big deal, so if it turns out to be too much of a problem
or adds too much latency to wait for the Hurd fix, we could apply this
patch.

WDYT?

Ludo’.