Dumb robocopy problem

[TheKrell]

I'm trying to use robocopy to copy (with file protections) a folder on one disk to another disk on the same W10 computer. I can't get the stupid program to do anything! I have tried this from an admin command window:

# robocopy "f:\My Old Directory" "e:\My New Directory" /copyall

and the darn thing just says "skipped". I have Googled this issue (spaces in directory names) all day and the MS tech portal (along with everybody else on earth) says that is the correct form of the command. See anything wrong with it?

 

[TheForce]

We've addressed win10 file sharing issues elsewhere. There's even a firewall for your local network that you need to disable to use win10 file sharing in your local private LAN. If in windows 10 file explorer you can see the other computer in the Network you are well on your way to getting the dozens of settings right for file sharing. It's not only the sender that needs proper security and sharing settings, it's also the receiver that may be the one that is rejecting the copy command. Win 10 has a network trouble shooter but my experience is that rarely works unless it's something simple like your ethernet cable is not connected, which you should be able to see physically. I also have had bad luck with googling for an answer because most of the solutions are based on older versions of win10 so much of what they tell you no longer applies. Frustrating and as Clinton used to say- "I feel your pain."

So far, the best solution was from harshness who suggested I install a network drive and that is working for me 90% of the time but it is slower than direct transfer. It could be 100% and just as fast if I change the way I do some things. His solution, unfortunately requires changes to the way you do things and how your hardware storage is structured.

 

[TheKrell]

We've addressed win10 file sharing issues elsewhere. There's even a firewall for your local network that you need to disable to use win10 file sharing in your local private LAN. If in windows 10 file explorer you can see the other computer in the Network you are well on your way to getting the dozens of settings right for file sharing. It's not only the sender that needs proper security and sharing settings, it's also the receiver that may be the one that is rejecting the copy command. Win 10 has a network trouble shooter but my experience is that rarely works unless it's something simple like your ethernet cable is not connected, which you should be able to see physically.

Thank you Don but I'm lost. Is this post in the wrong thread? I'm trying to use robocopy between two disks on the same computer.

 

[klang]

Try a space after the directory name before the closing quote. ie: "f:\My Old Directory "

 

[TheKrell]

Try a space after the directory name before the closing quote. ie: "f:\My Old Directory "

Thanks Klang. Yup; I tried that already with no effect. My understanding of that recommendation is that a \ is an escape character, and if you don't terminate your path with a \, then the space is not needed. (If you put \ in without a space, then the closing quote is gobbled.)

This is driving me nuts. What perverse software engineer wrote this gnarly piece of software? It seemed so promising at first. What do I have to do? Boot up Linux and use rsync?

 

[TheForce]

sorry Krell, misunderstood. I always use "Copy" and "Paste" to a bunch of selected files or folders to do what you want to do. It has never failed.

But in your post, I see you have included " in illogical places.

 

[harshness]

I don't think robocopy has a force option but I'm assuming that there isn't anything at the destination before you run the command. Does the destination directory exist or has running the command put a directory or file by that name there?

I get the feeling that whatever your actual command line is, it is trying to copy all the files to a single file and not a directory so after the first file is copied and given the destination as a name, any successive files are skipped because file destination already exists.

You need to make sure you have write privileges on the destination. This can be a problem if the drive came from another computer or device and you haven't established ownership.

If you use characters other than the basic non-white-space stuff in your file names, you're going to hate working in pretty much any command line environment.

 

[TheKrell]

sorry Krell, misunderstood. I always use "Copy" and "Paste" to a bunch of selected files or folders to do what you want to do. It has never failed.

No worries. I can't use copy/paste because it alters the file protections. I have about 1TB of small files in (usually) user-specific directories, and I can't lose those file privileges. Robocopy keeps them with the copyall switch.

don't think robocopy has a force option but I'm assuming that there isn't anything at the destination before you run the command. Does the destination directory exist or has running the command put a directory or file by that name there?

I get the feeling that whatever your actual command line is, it is trying to copy all the files to a single file and not a directory so after the first file is copied and given the destination as a name, any successive files are skipped because file destination already exists.

You need to make sure you have write privileges on the destination. This can be a problem if the drive came from another computer or device and you haven't established ownership.

Yes, the source and target directories exist. The target directory is empty and remains empty. I have tried this before without spaces in the pathnames and it worked. I accidentally created a new directory on my target disk once. The source disk was from another computer, but I can see all the files w/o issue as administrator. I'm lost. Windows drives me crazy.

 

[harshness]

The target directory is empty and remains empty.

You've tried deleting the destination directory before invoking the command? I can see where it might get bent about the root directory of what you're trying to copy already existing (though you would perhaps expect it do copy it to a subdirectory of the same name).

You mentioned using the backslash as an escape character, but Windows (both CMD and PowerShell) uses the carat (stupidly, the carat is valid in file and directory names). Whomever dreamed up the DOS parser was surely smoking printer ribbons and backup tape.

Quotes, Escape Characters, Delimiters - Windows CMD - SS64.com

 

[harshness]

The source disk was from another computer, but I can see all the files w/o issue as administrator.

Seeing a directory listing and being able to access the files named therein is two entirely different acts. Administrator rights in Windows aren't the same as superuser rights in *nix. Of course if you can type the files or load them into notepad, that's not the problem.

I, and I suspect Don, have been through this a time or two and it can be a real bearcat to take over a disk from another installation as Windows assigns numbers to named accounts and they vary with each install.

 

[Foxbat]

In Windows 10, do you run the Command Shell/Powershell "As Administrator"? as opposed to just logging in with the Windows Administrator account and launching a CMD process?

Also, if you type in icacls "F:\My Old Directory" what does it show for Privileges?

 

[TheKrell]

You've tried deleting the destination directory before invoking the command?

I didn't try that. I'll try it on Monday. Thanks for the suggestion.

In Windows 10, do you run the Command Shell/Powershell "As Administrator"?

I did.

Also, if you type in icacls "F:\My Old Directory" what does it show for Privileges?

Excellent idea. I've examined the privileges on the source disk using Properties, and I even added my admin account to the whole directory tree, without fixing this issue. But perhaps it's another one of those Windows utilities that silently does nothing. I'll try that command on Monday as well.

 

[TheKrell]

Also, if you type in icacls "F:\My Old Directory" what does it show for Privileges?

It shows this:

NT AUTHORITY\Authenticated Users: (I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM: (I)(OI)(CI)(F)
BUILTIN\Administrators: (I)(OI)(CI)(F)
BUILTIN\USERS: (I)(OI)(CI)(F)

 

[Foxbat]

Does not appear to be anything in the permissions since they're all (F). Unfortunately, I'm not a RoboCopy user so I'm not much help from here…

 

[Neutron]

Instead of robocopy can you use PowerShell? Copy-Item is the command and it would look like this:

Copy-Item -Path "f:\My Old Directory\*" -Destination "e:\My New Directory" -Recurse

This will copy all files and subdirectories from your original location into the new location and keeps the directory structure from your old directory.

You can even use the -Force switch at the end of that command.

 

[harshness]

I use rsync as it is:

1. FREE (as in free beer)
2. Well documented and stuff works until it is formally deprecated (after months of notice -- and only assuming you feel the need to update)
3. If updating the destination, it will check to see of the file already exists and won't copy if it does
4. Works predictably across Windows perversions
5. Works across platforms (within the limitations of each platform's security structure)

Building a system around pretty much any Microsoft shell command is a recipe for trouble as they change occasionally (mostly without warning) and the documentation is just short of awful. I know more than a few who effectively use Robocopy, but it is a battle to keep the scripts up-to-date and compatible (often involving checking the OS version within the script and branching around).

 

[Foxbat]

We were told by our Corporate IT group that one or two of the August Security Updates were going to break VBA apps and to thoroughly test with anything still based on VB 6. I passed this note on to our (remaining) developers and we found one or two Apps that have been around for a long time. I'm not sure if the original personnel who developed and wrote this App are still around. Thanks, Microsoft…

 

[harshness]

We were told by our Corporate IT group that one or two of the August Security Updates were going to break VBA apps and to thoroughly test with anything still based on VB 6.

Given that VB6 was declared "legacy" 11 years ago, they had a good run.

Anyone who develops using Microsoft tools is writing to a platform that shifts substantially every three years or so. With the advent of Windows 10 and Microsoft's desire to push "apps", that could easily get worse.

Our Autodesk software installations have several years worth of VC runtimes installed.