Robocopy fails with "ERROR 87 (0x00000057) Time-Stamping Destination"

[m6477]

With VirtualBox 5.0.12, both host and guest machines are Windows 7 Pro SP1 64-bit, robocopy.exe (v5.1.10.1027 as included with Windows 7) fails to copy files to a folder shared from the host thus:

C:\temp>robocopy \temp \\vboxsvr\temp

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows

-------------------------------------------------------------------------------

  Started : Mon Dec 21 01:00:28 2015

   Source : C:\temp\
     Dest = \\vboxsvr\temp\

    Files : *.*

  Options : *.* /COPY:DAT /R:1000000 /W:30

------------------------------------------------------------------------------

                           4    C:\temp\
100%        New File                  17        MyFile.txt.txt
2015/12/21 01:00:29 ERROR 87 (0x00000057) Time-Stamping Destination File C:\temp\MyFile.txt.txt
The parameter is incorrect.

The file has reasonable date/time stamps (created & modified); both host and guest drives use NTFS.

The exact same test, with the same files, works OK in 5.0.10, but when I update to 5.0.12 (including updating Guest Additions) it fails.

If I use xcopy (in VB 5.0.12) instead of robocopy, it works OK.

If I copy the files with Windows explorer (in VB 5.0.12), it works OK.

Possibly the problem is related to robocopy's normal practice of setting the destination file's modified date to 1 Jan 1980 while it is copying, then setting it to match the source file after all the data is copied.

Attached are the .vbox and log files (including those from v5.0.10, which works OK)

[Socratis]

I just tried to confirm the bug and I failed, i.e. robocopy works as intended (never had heard of that BTW, thanks for opening my eyes!). Tried on a 10.9.5 OSX host with VB 5.0.12. Original guest additions were 5.0.10. It worked. Updated GAs to 5.0.12, it worked. Command-line used (as admin):

Robocopy.exe C:\Users\Socratis\Links \\VBOXSVR\New_Folder\

BTW, you said "both host and guest drives use NTFS". Actually the guest doesn't really know or care what filesystem the share is located on.

[m6477]

... the guest doesn't really know or care what filesystem the share is located on

I suspected this to be the case but better to give too much information than neglect to mention something that might be important. (An internet search for that robocopy error suggests that it may occur with some specific file systems, due to incompatibilities in how the files systems handle time stamps.)

Further information...

I can reproduce the problem on two separate hosts, both Windows 7. One guest machine has been around for several years (updated through various VB versions), using robocopy without problems (and with the same shared folders) until now. One guest machine is new, with a clean installation of Windows 7, just to check that there was nothing wrong with the first guest.

In all cases the host machine has UAC disabled ("Never notify").

On one guest, UAC is disabled. The other (clean Windows installation) has the default UAC setting, and the problem occurs whether I run from a "normal" command prompt or an elevated ("as Administrator") command prompt.

Although robocopy reports an error, it does actually copy the file and sets the "modified" time to the correct value. While the file is being copied the "modified" time is set (as expected) to 1980 (checked on host, while copying a large file from guest) and then it is set to the correct time when the copy finishes.

I get the same problem (error 87) with a Windows 10 guest on a Windows 7 host.

Can somebody else try to reproduce the problem with a Windows host? I don't have ready access to any other host. (In theory I could install Linux on a spare host machine and try it - in practice my Linux skills are limited. In any case I need it to work on a Windows host.)

[sunlover]

Thanks for reporting this problem. Fixed in VirtualBox 5.0 r104829. Please install the latest Windows build from https://www.virtualbox.org/wiki/Testbuilds

The guest additions update is not required.

[m6477]

I just installed VirtualBox-5.0.13-104829-Win and that seems to have fixed the problem.

Thanks

[Frank Mehnert]

Thanks for the feedback! Fix is part of VBox 5.0.14.