Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

"invalid path 0 files copied" Error while using xcopy command

Tags:

Hi I have this little command to copy files in a batch, which will help because I do this specific copy multiple times a day. The problem occurs while using the xcopy command. Everything is in order, but I am receiving this error: "Invalid path 0 files copied". Here is the code:

C:\Windows\System32\xcopy  /Y "C:\Users\Ryan\Desktop\mmars_pub\" "C:\Users\Ryan\Desktop\Dropbox\MMARS\mmars_pub\"

I'm using the full path to the xcopy executable because I was having trouble configuring the path environment variable to function properly. I would imagine that it shouldn't affect the result though. I read somewhere about the "Prevent MS-DOS-based programs from detecting Windows" checkbox that should fix the issue, but I just can't seem to find that. Any help appreciated.

like image 665
frontin Avatar asked Sep 15 '14 04:09

frontin


People also ask

How do I copy files using xcopy?

Press F if you want the file or files to be copied to a file. Press D if you want the file or files to be copied to a directory. You can suppress this message by using the /i command-line option, which causes xcopy to assume that the destination is a directory if the source is more than one file or a directory.

Does xcopy still work in Windows 10?

Xcopy Command AvailabilityThis command is available from within the Command Prompt in all Windows operating systems including Windows 10, Windows 8, Windows 7, Windows Vista, Windows XP, Windows 98, etc. You can also access the command in MS-DOS as a DOS command.

Which is better copy or xcopy?

In most cases copying a single file is best done with the COPY command. When copying a single file with XCOPY, there is no option to indicate if the destination is a filename or a directory (with the filename defaulting to that of the source file).

What is the difference between copy and xcopy in CMD?

xcopy is an external program, while copy is part of the interpreter (cmd.exe, command.com). This means that xcopy might not be present on another machine or a rescue disk. Since we have Windows and rescue CDs, that isn't really an issue anymore. copy can concatenate files.


1 Answers

Original answer

Remove the ending backslash from the source folder path

C:\Windows\System32\xcopy.exe  /Y "C:\Users\Ryan\Desktop\mmars_pub" "C:\Users\Ryan\Desktop\Dropbox\MMARS\mmars_pub\"

edited 2015/10/01

While the original question used a literal path, and the indicated solution will solve the problem, there is another option. For literal paths and in cases where the path is inside a variable and could (or not) end in a backslash, it is enough to ensure that the ending backslash (if present) is separated from the quote, including an ending dot.

xcopy /y "x:\source\." "x:\target"
xcopy /y "%myVariable%." "x:\target"

This ending dot will not interfere in files/folders names. If there is and ending backslash, the additional dot will simply refer to the same folder. If there is not ending backslash as in windows files and folders can not end their names with a dot, it will be discarded.

BUT if the output of the xcopy command will be processed, remember that this additional dot will be included in the paths shown.


note: The solutions are above the line. Keep reading if interested on why/where there is a problem.

Why xcopy "c:\source\" "d:\target\" fails but xcopy "c:\source" "d:\target\" works?

Both commands seems to have valid path references, and ... YES! both are valid path references, but there are two elements that work together to make the command fail:

  • the folder reference is quoted (note: it should be quoted, it is a good habit to quote paths as you never know when they will contain spaces or special characters)
  • xcopy is not an internal command handled by cmd but an executable file

As xcopy is an external command, its arguments are not handled following the cmd parser command line logic. They are handled by the Microsoft C startup code.

This parser follows two sets of rules, official rules

  • Arguments are delimited by white space, which is either a space or a tab.

  • A string surrounded by double quotation marks is interpreted as a single argument, regardless of white space contained within. A quoted string can be embedded in an argument. Note that the caret (^) is not recognized as an escape character or delimiter.

  • A double quotation mark preceded by a backslash, \", is interpreted as a literal double quotation mark (").

  • Backslashes are interpreted literally, unless they immediately precede a double quotation mark.

  • If an even number of backslashes is followed by a double quotation mark, then one backslash (\) is placed in the argv array for every pair of backslashes (\\), and the double quotation mark (") is interpreted as a string delimiter.

  • If an odd number of backslashes is followed by a double quotation mark, then one backslash (\) is placed in the argv array for every pair of backslashes (\\) and the double quotation mark is interpreted as an escape sequence by the remaining backslash, causing a literal double quotation mark (") to be placed in argv.

and undocumented/non official rules (How Command Line Parameters Are Parsed)

  • Outside a double quoted block a " starts a double quoted block.
  • Inside a double quoted block a " followed by a different character (not another ") ends the double quoted block.
  • Inside a double quoted block a " followed immediately by another " (i.e. "") causes a single " to be added to the output, and the double quoted block continues.

This parser sees the sequence \" found at the end of the "first" argument as a escaped quote that does not end/closes the argument, it is seen as part or the argument. And the "starting" quote of the "second" argument is just ending the double quoted block BUT not ending the argument, remember that arguments are delimited by white space.

So while it seems that the command line arguments are

     v           v            v......argument delimiters
      v.........v v..........v ......quoted blocks
xcopy "x:\souce\" "x:\target\"
       ^.......^   ^........^  ......argument data
       arg #1      arg #2

       arg #1 = x:\source\
       arg #2 = x:\target\

the actual argument handled by xcopy is

     v                        v .....argument delimiters
      v......................v  .....quoted block
xcopy "x:\souce\" "x:\target\"
       ^.....................^  .....argument data
      arg #1    

      arg #1 = x:\source" x:\target"

When the ending backslash is removed or the additional dot included, the closing quote in the argument will not be escaped, it will close the quoted block and the space between arguments will be seen as a delimiter.

like image 59
MC ND Avatar answered Sep 17 '22 15:09

MC ND