It is difficult to touch a file with a relative mtime across different OSes as POSIX touch -d is rigid and POSIX date is inedequate to print timestamp of a relative date (OpenBSD uses date -r ..., FreeBSD uses date -v-2M while GNU accepts -d '-2 min'
Just use python os.utime()
Original description:
The case may randomly fail if we test it with command " while llvm-lit tools/lld/test/ELF/lto/cache.ll; do true; done". It is because the llvmcache-foo file is younger than llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6. But due to timestamp precision reason their timestamp is the same. Given the same timestamp, the file prune policy is to remove bigger size file first, so mostly foo file is removed for its bigger size. And the files size is under threshold after deleting foo file. That's what test case expect. However sometimes, the precision is enough to measure that timestamp of llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are smaller than foo, so llvmcache-349F039B8EB076D412007D82778442BED3148C4E and llvmcache-A8107945C65C2B2BBEE8E61AA604C311D60D58D6 are deleted first. Since the files size is still above the file size threshold after deleting the 2 files, the foo file is also deleted. And then the test case fails, because it expect only one file should be deleted instead of 3. The fix is to change the timestamp of llvmcache-foo file to meet the thinLTO prune policy. The same fix is applied to llvm code at https://reviews.llvm.org/D52452. Patch by Luo Yuanke.