David Michael <fedora....@gmail.com> 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’.
