[Issue 20370] New: On POSIX, std.file.copy only copies the file times at second precision

[d-bugmail at puremagic.com]

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 at puremagic.com
          Reporter: issues.dlang at 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 utimensat
would 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.

--