|
* ta/ensure_dir_eexist:
filelib_SUITE: strenghten tests of filelib:ensure_dir/1
Don't return a false {error,eexist} in filelib:ensure_dir/1
OTP-8389 Because of a race condition, using filelib:ensure_dir/1 from
multiple processes to create the same path or parts of the same
directory structure, filelib:ensure_dir/1 could return a
meaningless {error,eexist}. That race condition has been
eliminated, and {error,eexist} will now be returned only if there
exists a regular file, device file, or some other non-directory
file with the same name. (Thanks to Tuncer Ayaz.)
|
|
This is about the non-atomicity of filelib:ensure_dir/1.
When using filelib:ensure_dir/1 from multiple processes to create
the same path or parts of the same directory structure (which happens
with rebar's worker processes) it happens quite a lot that between
a file:read_file_info/1 and file:make_dir/1 one of the other procs
has already created the directory we want to create.
mkdir(1) says one of the following for -p depending on which Unix
like system you're on:
"no error if existing"
"no error will be reported if a directory given as an operand already
exists"
I've seen more than one Erlang project where the return value of
ensure_dir/1 is ignored completely.
To eliminate the race condition, call file:make_dir/1 without first
testing whether the directory exists. If it succeeds everything
is fine. Otherwise, if the error code is {error,eexists}, check
whether the directory exists. If it does, everything is fine;
if not, return {error,eexist} (which indicates that there
exists a regular file with the same name, or (more unlikely)
that another process removed the directory after the call
to file:make_dir/1).
Signed-off-by: Tuncer Ayaz <[email protected]>
|
