copy create's an almost empty (1K) file when a wildcard (*?) is used in the source & an output name is specified.

copy /D /V *?ample.png %homepath%/example.png

it works for some file types (.txt .rtf)
copy /D /V *?ample.txt %TEMP%\example.txt

interestingly wildcards in both the source & the destination fixes this,
copy "*xample.pdf" "%TEMP%/*xample.pdf"
but messes up the file name, it be comes: le.pdfxample.pdf

is this a Bug or bad syntax? i'm stumped.

i'm on Windows 7 x86_64
related questions
Using wildard with DOS COPY command corrupts destination file
How do I copy a file using a wildcard in Windows without appending?


I think it's a (mis-)used feature.
My Windown 10 help copy says:

To append files, specify a single file for destination, but multiple files for source (using wildcards or file1+file2+file3 format).

If the file format doesn't support simply concatenated source files, it's up to the user to keep this in mind.

Also Bali's answer to your first link fully answers your question.

A different workaround if there is only one source file with unclear name is:

for %A in (*?ample.png) Do copy "%A"  "%homepath%/example.png"
  • I disagree with the last sentence. A * means 0 or more chars; *? means one or more chars, which is a significant and useful difference. – Aganju Jun 12 '17 at 5:13
  • Copy should not assume it's "appending" files in this case, it should check & if multiple Binary files are given, exit with an error: Cannot concatenated Binary files. Microsoft, so misguided – Vencen Jun 13 '17 at 1:04

One issue with your use of wildcards... You're copying (potentially) many files into one single target, overwriting this poor file many times quite uselessly :). But, it did bring out this interesting 'feature'. I'm tempted to bring out my DOS floppies to check if the bug is that old.

I congratulate you on finding this interesting bug in DIR! The copied file end up corrupted. It's very consistent, does not depend on the /D /V switches, and only happens when overwriting the same file over and over again. The bug does not appear when using xcopy, which is good news for all windows users.

  • "One issue with your use of wildcards"....... Agreed, but that's not the issue here, & i disagree with "...happens when overwriting the same file...." happens the first time, every time. & thanks! – Vencen Jun 12 '17 at 19:02
  • I've played with it for a good 20 minutes this morning.... using willdcards for both input and output works like a charm under win7/x86. And the help for /B is "copy link as a link and not as its target" in a regular cmd window, but not, as I've jusrt checked in a VS2008 cmd session. – Michaël Roy Jun 12 '17 at 19:19
  • Sorry, I'll never get used to the return key behaviour on this site. – Michaël Roy Jun 12 '17 at 19:19
  • There seems to be a good many things yet to discover about copy... I wonder if the new VS2017 sdks provide their own version as well, To be continued... – Michaël Roy Jun 12 '17 at 19:22
  • The bug it were copy thinks "Binary files" are "ASCII text" file's when wildcards are use in the source & you specify a destination name, thats it! – Vencen Jun 12 '17 at 19:39

copy must know i file's type: "ASCII text" /A or a "Binary file" /B

A Binary file /B is assumed unless you are combining files.
but windows "assumes" when you put wildcards in the source & specify an output name you are combining files, & use's the "ASCII text" interpreter, so making a 1K empty file.

So the /B Parameter (Indicates a binary file)
must be used when using wildcards in the source with an output name specified,
on all non "ASCII text" file's.

copy /B /D /V *?ample.png %homepath%/example.png

Call it a Bug, a stupid Microsoft feature, but thats the way it is.


  • /B has long ago changed to mean 'copy the link and not its target'. /B lost meaning in DOS 6 and reappeared in its new form in Windows 95, if my memory is correct. The above bug is present in Windows 7/x86. – Michaël Roy Jun 12 '17 at 6:07
  • But I had to try the /B switch after reading your comment. You have found the source of the bug! If only we had the source code.... Seems like the MS team is not very good at cleaning up code. I wionder how many of these gems are still lurking around. – Michaël Roy Jun 12 '17 at 6:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.