aboutsummaryrefslogtreecommitdiffstats
path: root/erts/lib
diff options
context:
space:
mode:
authorTuncer Ayaz <[email protected]>2010-01-15 17:42:09 +0100
committerTuncer Ayaz <[email protected]>2010-01-18 18:13:03 +0100
commitecd339d1b4225627ecb371ed66d43139766fd4a8 (patch)
treece7e27deeb76f2b34ca48f85fd2fb050f3be846c /erts/lib
parente9adb6d0ef8426dec1f8f3211cabb49fc4464c01 (diff)
downloadotp-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 'erts/lib')
0 files changed, 0 insertions, 0 deletions