aboutsummaryrefslogtreecommitdiff
path: root/lib/std/macho.zig
diff options
context:
space:
mode:
authorAndrew Kelley <andrew@ziglang.org>2020-08-18 12:44:00 -0700
committerAndrew Kelley <andrew@ziglang.org>2020-08-18 12:44:00 -0700
commite2c741f1e7dbddabdbfc18a2520f5efa376899bc (patch)
treea64c3cf24abd931f8b87f1998de649334c65f414 /lib/std/macho.zig
parentbdb8c494188f699527e927f3a4d3b37d3823549f (diff)
downloadzig-e2c741f1e7dbddabdbfc18a2520f5efa376899bc.tar.gz
zig-e2c741f1e7dbddabdbfc18a2520f5efa376899bc.zip
std.cache_hash: additionally use file size to detect modifications
I have observed on Linux writing and reading the same file many times without the mtime changing, despite the file system having nanosecond granularity (and about 1 millisecond worth of nanoseconds passing between modifications). I am calling this a Linux Kernel Bug and adding file size to the cache hash manifest as a mitigation. As evidence, macOS does not exhibit this behavior. This means it is possible, on Linux, for a file to be added to the cache hash, and, if it is updated with the same file size, same inode, within about 1 millisecond, the cache system will give us a false positive, saying it is unmodified. I don't see any way to improve this situation without fixing the bug in the Linux kernel. closes #6082
Diffstat (limited to 'lib/std/macho.zig')
0 files changed, 0 insertions, 0 deletions