[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed fix for some race conditions in mkdir and install
From: |
Jim Meyering |
Subject: |
Re: proposed fix for some race conditions in mkdir and install |
Date: |
Sun, 17 Sep 2006 08:55:28 +0200 |
Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> By the way, I've just realized that it *is* possible to implement these
>> mkdir-like functions in a thread-safe manner (i.e. traversing via openat,
>> operating on files via mkdirat, chmodat, etc.), while remaining efficient
>> (O(n)). The only assumption is that the target directory name does not
>> contain too long a sequence of existing unreadable directories (sum
>> of length of names + slashes > PATH_MAX).
>
> I initially tried something like that, but got too confused by it,
> perhaps partly because I wanted to fall back on something like the
> current approach when mkdirat didn't work (which is a common case
> these days, even on GNU/Linux systems, alas).
What do you mean?
Of course, for at-function-syscall support, you need Linux 2.6.16 or
newer, but gnulib's mkdirat emulation works well also with /proc/self/fd/N
support, which is available back at least to linux-2.4.x.
Admittedly, /proc isn't always available, but I wouldn't say that's "common".
> The current code is still too complicated for my taste --
I agree. But we can save the rewrite for later :)
> I'd be quite
> surprised if it were bug-free. I considered ripping out the
> open(".")/fchdir part of the code, since it's simpler if you assume
> that you _always_ create a subprocess, but decided that in this case
> simplicity had to yield to performance.
I'm glad you did.