file(COPY truncates timestamp on Linux, leading to erroneous behaviour
Problem description:
On Linux, file(COPY
sets the timestamp of the generated file to a truncation of the original file's timestamp with the precision being seconds. This means, that the copy is considered older than the original. In a use case, where you copy the same file twice within one second, the policy of not copying if the timestamp has not changed leads to the second copy operation being no-op despite the source file having changed.
Minimum working example:
- Clone https://gitlab.dune-project.org/dominic/cmake-filecopy-bug
- run
./reproduce.sh
- Observe how the time stamps differ and how the content of the two files differs after a second copy.
Most probable solution:
It seems that the handling of timestamps is still based on second-precision utime
instead of milli- or nano-second precision utimensat
.
Related issues:
- #19204 would be a remedy for the issue that disables the copy prevention in case of matching timestamps.
-
#19335 (closed) is also requesting millisecond-precision timestamps, though for
string(TIMESTAMP
. - #19852 has more timestamp-related issues that might be solved by a similar fix