## Summary `build_cache.File_Metadata.git_restore()` is responsible for putting back the image file metadata that Git doesn’t record. In “quick” mode, it trusts the filesystem metadata and only puts back things that Git actively breaks. This does not work for atime and I don’t see how it ever did. Version: main \ Environment: ``` $ cat /etc/debian_version 13.3 $ uname -a Linux lucas 6.12.48+deb13-arm64 #1 SMP Debian 6.12.48-1 (2025-09-20) aarch64 GNU/Linux ``` ## Steps to reproduce ``` $ ch-test -f test/build/55_cache.bats:'difficult files' ``` ## Expected behavior Test passes. ## Actual behavior Test fails: ``` ✗ cache: difficult files [...] -1 -rw-r----- 23 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.2246581990 ./gitrepo/.git/HEAD () +1 -rw-r----- 23 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.1886536480 ./gitrepo/.git/HEAD () 2 drwxr-x--- 0000 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.1606501090 ./gitrepo/.git/branches () -1 -rw-r----- 92 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.2246581990 ./gitrepo/.git/config () -1 -rw-r----- 73 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.2246581990 ./gitrepo/.git/description () +1 -rw-r----- 92 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.1886536480 ./gitrepo/.git/config () +1 -rw-r----- 73 m=2026-02-22T12:09:37.1606501090 a=2026-02-22T12:09:37.1886536480 ./gitrepo/.git/description () [... and several more ...] ``` ## Comments Recall that atime is “access time”. It’s updated when a file is accessed (opened? read? I’m not sure), at least in theory because there are a lot of mount options to control when if ever it’s updated. I’m pretty sure what is happening is that during the commit, Git must read the contents of the changed files, thus updating the atime. The quick restore then leaves this new atime. But when the image is deleted and rebuilt as part of the test, the full restore puts back the old atime left by the Dockerfile instruction. This then does not match. AFAICT this behavior is what has been happening all along, so I don’t know how it ever worked (i.e. I fear it’s a [schroedinbug](http://www.catb.org/jargon/html/S/schroedinbug.html)). Perhaps it’s only now surfacing due to changed kernel version, mount options, etc. atime is kind of unreliable (see all the mount options available to work around it) so I wonder if we should bother saving it at all. MR !2013 works around the bug by disabling quick restore.