On 09/02/2023 19:57, Chet Ramey wrote:
On 2/9/23 12:11 PM, Rob Landley wrote:
Therefore, when there is competition among many calls to coreutils
`mkdir -p`. The first instance will create the target, and the rest
instances will fail on the system call of mkdir. But since they find
the target is already created and is a directory, they will not
complain about the error system call mkdir. That is why I never see an
error similar to that of bash loadable `mkdir -p`. Is it so?
Right. That suggests a bug in the bash loadable,
as it should not fail in this case.
Which would be a question for bash's maintainer, not coreutils. :)
It's a question of how you deal with the race condition in the original
script. Do you check first, then mkdir (bash loadable), or mkdir, then
check failure (coreutils)? There's a race condition with either approach.
For me this kind of falls under the pattern of
"it's better to ask for forgiveness rather than permission".
I.e. don't check if an operation is supported,
rather try it and handle failures.
Following that pattern generally reduces races and coupling.
In this case coreutils tries the mkdir() and handles exceptions.
if mkdir(d) == EEXIST
return stat(d) == S_ISDIR
I see the bash example mkdir loadable here:
http://git.savannah.gnu.org/gitweb/?p=bash.git;a=blob;f=examples/loadables/mkdir.c
The final stat/mkdir call looks like the following,
and could possibly be adjusted to the pattern above?
if stat(d) == error
return mkdir(d) == success
In any case `mkdir -p` shouldn't be returning failure
if an existing _directory_ is there.
Agreed there are still races in both implementations
in that something else could replace / remove the directory
_after the mkdir -p call completes_
But that would be unusual, and generally not the case
for multiple instances of the same script.
Also worth noting that using a mkdir loadable for speed
should be carefully considered, as mkdir isn't a trivial
operation wrt cross platform issues, permissions,
and SELinux contexts etc.
cheers,
Pádraig
