2

I have the file DWA_160_drv_RevB_2_2-42_all_en_20130313.zip on Desktop. I want to copy it to a USB flash drive using CMD. I use the copy command to do that, but I'm getting bizarre results, i.e. the original file is about 30 thousand (!!) times bigger than the new file.

C:\Users\Sam\Desktop>
C:\Users\Sam\Desktop>dir dwa*
 Volume in drive C is Vista (ST1PT1)
 Volume Serial Number is D27C-,,,,

 Directory of C:\Users\Sam\Desktop

2013-10-10  11:56        23 324 179 DWA_160_drv_RevB_2_2-42_all_en_20130313.zip
               1 File(s)     23 324 179 bytes
               0 Dir(s)   3 318 292 480 bytes free

C:\Users\Sam\Desktop>copy dwa* d:\dwa-driver.zip
DWA_160_drv_RevB_2_2-42_all_en_20130313.zip
        1 file(s) copied.

C:\Users\Sam\Desktop>d:

D:\>dir
 Volume in drive D is CRUZER
 Volume Serial Number is 0085-,,,,

 Directory of D:\

2013-10-10  13:41               734 dwa-driver.zip
               1 File(s)            734 bytes
               0 Dir(s)   2 050 744 320 bytes free

D:\>

How can this be?... how is this possible? The command is completed successfully but the resulting file is like a drop of water in the ocean when you compare the size of it, and it is apparently corrupted.

Am I doing something wrong here?

I thought it might have to do with the way I type in the source and destination search path, so I added quotation marks. I can't say it helped.

D:\>c:

C:\Users\Sam\Desktop>copy "dwa*" "d:\dwa-driver.zip"
DWA_160_drv_RevB_2_2-42_all_en_20130313.zip
Overwrite d:\dwa-driver.zip? (Yes/No/All):
        0 file(s) copied.

C:\Users\Sam\Desktop>d:

D:\>c:

C:\Users\Sam\Desktop>copy "dwa*" "d:\dwa-driver.zip"
DWA_160_drv_RevB_2_2-42_all_en_20130313.zip
Overwrite d:\dwa-driver.zip? (Yes/No/All): y
        1 file(s) copied.

C:\Users\Sam\Desktop>d:

D:\>dir
 Volume in drive D is CRUZER
 Volume Serial Number is 0085-,,,,

 Directory of D:\

2013-10-10  13:56               734 dwa-driver.zip
               1 File(s)            734 bytes
               0 Dir(s)   2 050 744 320 bytes free

D:\>

So I decided to try using the full name of the source file, utilizing the auto-complete feature in CMD to make sure it is typed in correctly. And this time it worked! Here's the command.

D:\>c:

C:\Users\Sam\Desktop>copy DWA_160_drv_RevB_2_2-42_all_en_20130313.zip d:\dwa-d
river2.zip
        1 file(s) copied.

C:\Users\Sam\Desktop>d:

D:\>dir
 Volume in drive D is CRUZER
 Volume Serial Number is 0085-,,,,

 Directory of D:\

2013-10-10  13:56               734 dwa-driver.zip
2013-10-10  11:56        23 324 179 dwa-driver2.zip
               2 File(s)     23 324 913 bytes
               0 Dir(s)   2 027 417 600 bytes free

D:\>

So this time it worked!?!? How is dwa-driver2.zip different from dwa-driver.zip? And how does the original file - DWA_160_drv_RevB_2_2-42_all_en_20130313.zip - compare to dwa-driver.zip? To answer that I made a side by side textual and hex comparison. See screenshots below.

What exactly happens at line 6? Why is it copying first 5 lines without a problem and then gets stuck at line 6 (see WinMerge screenshot)? Both files are identical, up to line 6, and from that point forward no more data is copied to the new file. Why? Am I not allowed to use wildcard characters with the copy command?

Update


I'll just call it a bug and use the xcopy command because it accepts anything I throw at it. It doesn't matter if there are wildcard characters or not. It's unfortunate that xcopy command is not available in all modes of Windows and command prompt windows.

D:\>c:

C:\Users\Sam\Desktop>xcopy dwa* d:\dwa-driver3.zip
Does D:\dwa-driver3.zip specify a file name
or directory name on the target
(F = file, D = directory)? f
C:DWA_160_drv_RevB_2_2-42_all_en_20130313.zip
1 File(s) copied

C:\Users\Sam\Desktop>d:

D:\>dir
 Volume in drive D is CRUZER
 Volume Serial Number is 0085-,,,,

 Directory of D:\

2013-10-10  13:56               734 dwa-driver.zip
2013-10-10  11:56        23 324 179 dwa-driver2.zip
2013-10-10  11:56        23 324 179 dwa-driver3.zip
               3 File(s)     46 649 092 bytes
               0 Dir(s)   2 004 090 880 bytes free

D:\>

Screenshots


Click for larger view.

Text comparison between DWA_160_drv_RevB_2_2-42_all_en_20130313.zip and dwa-driver.zip:

winmerge winmerge

Size difference between dwa-driver.zip and dwa-driver2.zip:

explorer

Text comparison between dwa-driver.zip and dwa-driver2.zip in Beyond Compare 3:

bcompare bcompare

Hex comparison in Beyond Compare 3:

bcompare

  • I guess I will just have to use full file name when using the copy command. But I'm curious to know why this is a problem for Microsoft to use wildcard characters in file names. Why does the command stop writing the file exactly at this point? Is it a mere coincidence or is a there a more deeply rooted reason for why it stops writing exactly at that point? The command is apparently accepted and it works... even though it works only half-way and produces corrupted copies. It makes no sense... – Samir Oct 10 '13 at 13:58
  • what OS/ver you running? – Keltari Oct 10 '13 at 14:39
  • @Keltari Windows Vista Ultimate, 64-bit SP2. – Samir Oct 10 '13 at 15:34
  • Try with its sub command xcopy /E /Y /I dwa* d:\dwa-driver3.zip I am using the similar to copy a large file to another drive. – Harbinder Singh Jun 17 '14 at 15:48
  • 1
    > It's unfortunate that xcopy command is not available in all modes of Windows IIRC xcopy is included with XP and later, and available as a download for W2k and possibly 9x. But, seriously, do you really need to support anything older than XP? Unless you have that specific need, I would suggest that it's safe to assume availability. – Bob Dec 4 '14 at 11:53
4

copy command has two different behaviours, two different ways to use it.

The first one is used to copy files. This is the behaviour used when

  • The source is only one file and the target is not indicated (current folder is the target by default), it is a folder path or is only one file.

  • The source includes wildcards and the target is none (current folder) or a folder path

The second behaviour is used to combine multiple source files into one target file. This behaviour is used when

  • The target is one file and the source is a list of files separated by a + sign

  • The target is one file and the source includes wildcards

Your command, copy dwa* d:\dwa-driver.zip uses the second behaviour.

AND there is a big difference between the first and the second behaviour. By default, when copying the files are considered as binary data, but when the files are combined they are considered to be ASCII.

In your case, as the command is considered as a combination operation, the files are considered ASCII and the resulting file contains data in the source file up to the first 0x1A character (look in your hex dumps)

You can solve it indicating to the copy command that the operation must be binary

copy /b dwa* d:\dwa-driver.zip

And this will work as intended if only one file matches the wildcard. If more than one file matches it, they will be combined into the target file.

  • The 0x1A character is the ASCII sub character, used to indicate the end-of-file in some file systems. See: en.wikipedia.org/wiki/Substitute_character – Rob Feb 12 '15 at 11:56
  • @Rob, Yes, your link shows 0x1A as Ctrl-Z, what the MS documentation states as EOF for copy commmand while operating in ASCII mode – MC ND Feb 12 '15 at 12:14

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.