I get this result:
Try adding @admin as the first line of the function.
It works--can I get it to not copy the "System Volume Information" folder?
@admin
@leavedoswindowopen
Robocopy.exe {sourcepath$|noterm} {destpath$|noterm} /V /E /NP /R:1 /W:1 /COPYALL /PURGE
Add /XD "System Volume Information" to the end of the Robocopy.exe arguments, after /PURGE.
Great--I added one more folder to exclude and use left and right listers--looks ok?
@admin
@leavedoswindowopen
Robocopy.exe {leftpath$|noterm} {rightpath$|noterm} /V /E /NP /R:1 /W:1 /COPYALL /PURGE /XD "System Volume Information" "$RECYCLE.BIN"
Using the RoboCopy command supplied by Leo, I am being told that:
"The system cannot find the drive specified."
and
"The system cannot find the path specified."
The drive complained of is my U:\ drive, shown here in this screenshot of Opus:
I am trying to sync U:_Backups to F:_Backups, shown in the upper panel of the Opus window.
The button code as I said, is Leo's code, as follows:
[code]@admin
//ms-dos type to make modifier @leavedoswindowopen work
@leavedoswindowopen
Robocopy.exe {sourcepath$|noterm} {destpath$|noterm} /V /E /NP /R:1 /W:1 /COPYALL /PURGE[/code]
with the extra @admin tweak advised by Jon.
Can anyone see anything wrong with what I am trying to do? Thanks.
Is U: a mapped network drive? By default, Windows keeps separate lists of drives mapped as a normal user and an elevated user, so it won't appear to the elevated Robocopy.exe.
You can change this using the EnableLinkedConnections registry setting: Technet: Some Programs Cannot Access Network Locations When UAC Is Enabled.
This option was broken somewhat in Windows 8 and 8.1, and only works properly for drive letters that point directly at a \computer\share and not a sub-folder of a share. I don't know if it was fixed in Windows 10.
it is a mapped network drive. The drive is a WD MyBook drive connected to s USB3 port on my Netgear R7000 router. It can be accessed by all of the PCs in the house.
I shall check the references you have given, and report on success or otherwise.
Thanks Leo.
Hello Leo...
I have tried EnableLinkedConnections, but no joy, I'm afraid.
I have proved the button code on paths which did not involve the U: drive, so, I am coming to the conclusion (reluctantly) that RoboCopy has a problem of some sort with the mapping of the U: drive per se.
I am able to address the path using \READYSHARE instead of U:, so, I have tailored the button code to use \READYSHARE_Backups for the source, and I still get the same result.
I am starting to think RoboCopy cannot access the router-connected drive, even though Opus and FileExplorer both can.
Does that idea make any sense to you?
I have now experimented with XXCOPY and XCOPY as well as RoboCopy.
Neither XXCOPY nor RoboCopy recognises the U: drive (or the \READYSHARE variant).
XCOPY does recognise the U: drive, but has a much more limited switch set. It cannot delete a file or folder which is not present in the source, so cannot be used to clone a folder set.
I am now reconsidering the Opus Synchronize function.
My reasons for looking elsewhere were speed and automation, but at the moment, it seems as if Opus is the only tool which can do the job at all.
To verify robocopy won't handle your U: drive, I'd suggest you..
- open a cmd prompt
- run cd /D U:
- run robocopy.exe .. (with the complete command line from the button)
If this already fails at the point where you are switching current directory with the "cd" command, robocopy can't do any better. Then it still has something to do with that "EnableLinkedConnections" issue, which I came across myself as well - and it s*cks.. o)
The problem is unrelated to Robocopy, XCopy, or any specific tool.
Open an elevated command prompt and the prompt itself won't normally see the U: drive either. Network drives mapped in an un-elevated context are not visible in an elevated context, and vice versa, by default.
The EnableLinkedConnections registry setting is meant to remove this restriction. You may need to reboot and/or re-create the drive mappings for it to work.
Also note that if you are using a standard user account and elevating to a separate admin account, then the registry setting may behave differently. (I am not sure; just guessing about how it works under the hood of Windows).
We're veering away from anything to do with Opus here, so you may find better knowledge on a more generic Windows help forum, e.g. Superuser. The question is really just how to get your mapped drives recognised from an elevated context, specifically an elevated command prompt.
PS: Is there a reason we're using Robocopy or other external copy tools in the first place? I can't find it in the thread.
Fully agree.
The reason for using robocopy (or others) is triggering a sync from a button (I guess).
As far as I know and experienced, the sync that is built into DO needs manual setup each time.
Copy UpdateAll doesn't.
OTOH it's also odd to need to regularly sync things that require admin access to do.
I feel this thread may have lost sight of the goal while following one particular way to achieve that goal, but maybe I have missed or forgotten a detail.
Copy UpdateAll is only half a sync, since it does not remove files from dest, which no longer exist in source, correct?
Correct. (Although, as per my original prediction, it's proving to be simpler and quicker to delete & re-copy than to get Robocopy etc. to work.)
Bearing in mind, there are hundreds of folders containing thousands of files, I am looking to create a button to automate the process. Is this what I need?
Delete ALL FORCE NORECYCLE QUIET F:\Backups\*.*
Copy U:\Backups\*.* UNATTENDED=yes TO F:\Backups
Will Opus wait for completion of the Delete function before starting the Copy function?
Yes.