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

[David Michael]

On Thu, Feb 4, 2016 at 11:47 AM, Ludovic Courtès <address@hidden> wrote:
> 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…)

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