aboutsummaryrefslogtreecommitdiffstats
path: root/OTP_VERSION
diff options
context:
space:
mode:
authorMikael Pettersson <[email protected]>2014-05-14 16:23:02 +0200
committerMikael Pettersson <[email protected]>2014-05-14 16:51:15 +0200
commit78540afe8d4a15fe3d6c42208b82bde546e4c0c8 (patch)
tree471855440f987e13a8e4ba9efd6ad717ed7631eb /OTP_VERSION
parent5ade234d37600ea80dbb309f431c615937ea253d (diff)
downloadotp-78540afe8d4a15fe3d6c42208b82bde546e4c0c8.tar.gz
otp-78540afe8d4a15fe3d6c42208b82bde546e4c0c8.tar.bz2
otp-78540afe8d4a15fe3d6c42208b82bde546e4c0c8.zip
Fix efile_openfile() to handle stat() failure
If the initial stat() fails then efile_openfile() will still proceed to open() the file. If that succeeds and the caller passed a non-NULL pSize, then it will copy bogus data from the statbuf into *pSize. This has been observed to cause file:read_file/1 to return truncated file data with no error indication. The use case involved a large file system mounted via NFS, with some directories containing large number of files, and NFS mount options that allow the NFS client to return EIO if the NFS server does not respond quickly enough. Depending on the caching state of the client and server machines, a few stat() calls (fewer than 1 per 10 million) would take long enough to trigger EIO errors, but subsequent open() calls would succeed, and read_file/1 would return truncated data. This sequence of events has been observed via "strace" on beam.smp. Signed-off-by: Mikael Pettersson <[email protected]>
Diffstat (limited to 'OTP_VERSION')
0 files changed, 0 insertions, 0 deletions