digitalmars.D.bugs - [Issue 20370] New: On POSIX, std.file.copy only copies the file
- d-bugmail puremagic.com (35/36) Nov 08 2019 https://issues.dlang.org/show_bug.cgi?id=20370
https://issues.dlang.org/show_bug.cgi?id=20370 Issue ID: 20370 Summary: On POSIX, std.file.copy only copies the file times at second precision Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nobody puremagic.com Reporter: issues.dlang jmdavisProg.com Currently, on POSIX systems, after std.file.copy has copied the file, it sets the access time and modification times of the copy to be the same as the original using utime: utimbuf utim = void; utim.actime = cast(time_t) statbufr.st_atime; utim.modtime = cast(time_t) statbufr.st_mtime; cenforce(utime(toz, &utim) != -1, f, fromz); utime only has second precision (as shown by the cast to time_t). The result is that if you copy a file on a file system that supports sub-second precision (which should be most file systems), the copy will actually be considered newer than the original. E.G. if the modification time of the original was "2019-Nov-07 19:41:49.2518144", the copy would be "2019-Nov-07 19:41:49". So, std.file.copy should changed to use a function with sub-second precision.From the little bit of research I've done thus far, it looks like utimensatwould be the correct replacement (it having nanosecond precision and being from "IEEE Std 1003.1-2008 ('POSIX.1')"). It looks like FreeBSD and Linux both have this function, and druntime has it for both. I don't know if Mac OS X has it or not, but druntime does not have it for Darwin. Assuming that it's not just missing from druntime, we could use utimes on Mac OS X, which isn't as good as utimensat (utimes only has microsecond precision), but it's still better than utime. --
Nov 08 2019