Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
/COPY: DAT (or no /COPY specified) preserves the Date modified. Used it bazzilion times, if the "Date modified" is not preserved it's not Robocopy fault most likely.
Like i said, i have had a weird issues with preserving file attributes (not dates in particular, but rather ACLs and /A /H flags) when using robocopy to move files to/from NAS devices. In one case we had to use an EMC CLI tool similar to Robocopy to get the job done. So this is definitely something worth looking into. Just try copying the same data between 2 Windows boxes and see if the Dates are preserved with the same Robocopy script.
Is it folders that have the wrong time, if so you need /DCOPYAT, but other than that I'd expect it to work. There is a /TIMFIX option which you could look at?
If your command line is executed exactly as shown then I think the placement of the final " is effectively disabling all the parameters supplied to the command as they may be considered as part of the target name.
Leave a comment: