2

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?

Vencen
  • 53

3 Answers3

1

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"
LotPings
  • 7,391
1

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.

Source

Vencen
  • 53
1

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.