diff options
author | Tuncer Ayaz <[email protected]> | 2010-01-15 17:42:09 +0100 |
---|---|---|
committer | Tuncer Ayaz <[email protected]> | 2010-01-18 18:13:03 +0100 |
commit | ecd339d1b4225627ecb371ed66d43139766fd4a8 (patch) | |
tree | ce7e27deeb76f2b34ca48f85fd2fb050f3be846c /lib/stdlib/test/ets_tough_SUITE.erl | |
parent | e9adb6d0ef8426dec1f8f3211cabb49fc4464c01 (diff) | |
download | otp-ecd339d1b4225627ecb371ed66d43139766fd4a8.tar.gz otp-ecd339d1b4225627ecb371ed66d43139766fd4a8.tar.bz2 otp-ecd339d1b4225627ecb371ed66d43139766fd4a8.zip |
Don't return a false {error,eexist} in filelib:ensure_dir/1
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]>
Diffstat (limited to 'lib/stdlib/test/ets_tough_SUITE.erl')
0 files changed, 0 insertions, 0 deletions