# std.cache_hash: additionally use file size to detect modifications · gitcafe/zig

[View on GitCafe](https://git.cafe/gitcafe/zig/commit/e2c741f1e7dbddabdbfc18a2520f5efa376899bc)

Repository: [gitcafe/zig](https://git.cafe/gitcafe/zig)

Visibility: public

Requested revision: e2c741f1e7dbddabdbfc18a2520f5efa376899bc

Requested commit: e2c741f1e7dbddabdbfc18a2520f5efa376899bc

Commit: e2c741f1e7dbddabdbfc18a2520f5efa376899bc

Tree: a64c3cf24abd931f8b87f1998de649334c65f414

Author: Andrew Kelley

Committer: Andrew Kelley

## Message

```
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

```

## Parents

- [bdb8c494188f699527e927f3a4d3b37d3823549f](https://git.cafe/gitcafe/zig/commit/bdb8c494188f699527e927f3a4d3b37d3823549f?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zig/tree/e2c741f1e7dbddabdbfc18a2520f5efa376899bc?format=markdown)