cp -p not preserving date and time

[cmendl]

Microsoft Windows [Version 10.0.14393]

Copying files using cp -p does not retain date of source file (on Windows filesystem)

user@SCHORSCH:/mnt/c/tmp$ cp -p foo.txt foe.txt
user@SCHORSCH:/mnt/c/tmp$ ls -la
total 28
drwxrwxrwx 2 root root 0 Apr 17 14:17 .
drwxrwxrwx 2 root root 0 Apr 17 14:16 ..
-rwxrwxrwx 1 root root 7 Apr 17 14:17 foe.txt
-rwxrwxrwx 1 root root 7 Apr 17 14:16 foo.txt

Copied file "foe.txt" should have date and time of source file "foo.txt", but instead gets assigned current time.

[stehufntdev]

Are you seeing the same behavior in lxfs (e.g. root directory) or just in drvfs? IIRC, we recently found an issue with drvfs timestamps but I'll double check.

[cmendl]

I'm seeing the issue only when copying files within the windows filesystem; cp -p works as expected within my home directory of the bash shell, and also when copying a file form the windows filesystem into my home directory.

Chris

[SvenGroot]

This is due to the way that Windows updates timestamps, which it only does when the handle closes. When you use "cp -p" it opens the target file, writes to it, sets the timestamp, then closes it. Setting the timestamp doesn't use the same handle due to our VFS design, so when the file is closed Windows updates the timestamp again because that handle was written to.

We're working on ways to mitigate this issue.

[sunjoong]

@SvenGroot - Because make is a timestamp based utility, it would make problems. I hope it will be fixed soon.

[jstarks]

This should be fixed in insider build 17063.

[michael-ts]

@jstarks I'm seeing this bug in the WSL(2) in Windows 10, however the issue is that while the seconds part of the timestamp is preserved, the milliseconds part is zeroed out in the destination file.