none
Robocopy modified date on destination RRS feed

  • Question

  • Hi All.

    I am trying to write something that will sync my local directory with a Sharepoint repository to save me the hassle of having to individually upload files from my desktop or download ones placed on Sharepoint by other users.

    I've looked around and robocopy appears to be the best bet for this. I've mapped two drives on my desktop: x:\ is the root of the local folder I want to sync and y:\ is the remote Sharepoint repository.

    I could use the /mir parameter, but my concern there is that others will be adding files to the destination which I won't have on my desktop - hence robocopy will see those as deletions and delete them from Sharepoint - making me less than popular with colleagues!!

    My plan was to run two command lines: first one copies any new or modified files from x:\ to y:\ and the second does it in reverse. That way, the two are kept in sync without the risk of deletions.

    The issue I have is that when copying from source to destination, regardless of whether I supply the /copy:dt parameter, the modified date on the destination is set to now. It seems that whilst copying, it is retaining the file's own modified date, but once the copy is complete the modified date is set to now. So when I come to run the second line, it sees everything on the Sharepoint site as being newer than the source and tries to copy everything back, not just new or modified files.

    Any pointers here? If I use Windows Explorer to do a drag and drop, it maintains the modified date as expected. If I use xcopy or normal copy, I get the same issue with the modified date changing to now.

    My two lines are as follows:

    robocopy x:\ y:\ /E /XO /copy:DT /dcopy:T /LOG+:"SYNC_FBS_TR.LOG" /TEE
    robocopy y:\ x:\ /E /XO /copy:DT /dcopy:T /LOG+:"SYNC_FBS_TR.LOG" /TEE

    Is it possible that the way Sharepoint is set up it is setting the modified date itself after the copy? Any other pointers?

    Any help greatly appreciated!

    Rob.

    Tuesday, May 19, 2015 8:51 AM

Answers

  • I know of no difference in dates using robocopy (it has always worked reliably in every case I have used it, for more than 15 years now), but in any case, this is not the right place to ask robocopy questions. I would suggest searching for solutions. You can also find a general Windows OS forum and ask your question there.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, May 19, 2015 2:23 PM
    Moderator

All replies

  • When you use a hard disk partition as a destination then you will see that this is a SharePoint limitation, not a robocopy property. Regardless of the above, this is not a scripting (=programming) problem. You need to resolve it in a SharePoint forum, e.g. here.

    Tuesday, May 19, 2015 9:25 AM
  • Not sure I understand your response - but thanks for the reply. I've discovered that if I use Powershell command Copy-Item, it sets the modified date correctly at the destination. So I don't think the fact that I mapped a drive to a Sharepoint folder makes any difference in this case. For some reason, Robocopy is giving a different result from Powershell Copy-Item in terms of retaining the modified date at the destination.
    Tuesday, May 19, 2015 12:24 PM
  • I know of no difference in dates using robocopy (it has always worked reliably in every case I have used it, for more than 15 years now), but in any case, this is not the right place to ask robocopy questions. I would suggest searching for solutions. You can also find a general Windows OS forum and ask your question there.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, May 19, 2015 2:23 PM
    Moderator