XCOPY giving Invalid Switch error

Posted on 2006-06-21
Last Modified: 2013-12-28
Hi Experts.
Trying to run the following XCOPY command from a batch file on my Win98se boot floppy booted with CD-Rom Support to copy the win98 folder from my CD to 2nd hard drive partition (D:\).

xcopy G:\win98 D:\WIN98 /S /W /I /F /H

It works perfectly well from within Windows, but from the boot floppy DOS Mode I receive the following error:

Invalid switch   -   -  /F

I've tried the switches as lower and uppercase (shouldn't make any difference apart from the fact that it just reflects this in the error message), and tried them in every permutation (ie. order) after the <source> and <dest> parameters.  I've also tried providing the directories with trailing backslashes.

If I leave out one of the switches, it jumps to the next and tells me that is invalid.

The strange thing is that XXCOPY (which uses mostly the same switches) is also giving me an "invalid switch" error when trying to perform the same folder copy.


XCOPY source [destination] [/A | /M] [/D[:date]] [/P] [/S [/E]] [/W] [/C] [/I] [/Q] [/F] [/L] [/H] [/R] [/T] [/U] [/K] [/N]

Presumably that's the recommended order that the switches should be used, or else they would have been shown alphabetically.

/S   Copies directories and subdirectories except empty ones.
/W  Prompts you to press a key before copying.
/I    If destination does not exist and copying more than one file, assumes that destination must be a directory.
/F   Displays full source and destination file names while copying.
/H   Copies hidden and system files also.

Have I overlooked something blatantly obvious here?
I've usd XCOPY on numerous previous occasions with full success.

Question by:BillDL
  • 7
  • 4
  • 3
  • +1
LVL 30

Expert Comment

ID: 16951256
>>/F   Displays full source and destination file names while copying.
Full names are NOT available through DOS -- Long file name support is a Windows Feature

Why not do:

xxcopy G:\win98 d:\win98 /clone

And then add any other switches you want to the end of that command
LVL 30

Expert Comment

ID: 16951334
The Win98 Files on CD likely wont have long file names anyway. If they do, you can use some windows utility to backup the names & then restore them after copy. Assuming the /F applies to long file names, then it won't work in a DOS bootup (but will in DOS Mode within Windows).
LVL 38

Author Comment

ID: 16952631
Thanks for your comments, callrs.
Yes you are obviously correct about the long file name support, but as you said, neither of the quoted paths in my command exceed the DOS 8.3 file naming convention.  When I removed the /F switch, it then told me that /H was an invalid switch.  That's just about the time I gave up in disgust.

My copies of XXcopy.exe and XXcopy16.exe don't seem to support the /clone switch, at least it isn't output as an option when I check the syntax with xxcopy /?  xxcopy /help  xxcopy16 /? or xxcopy16 /help.  In fact, the copy of XXcopy.exe I have was from some Windows XP custom boot floppy I downloaded, and seems to be a 32-bit application that might not run from DOS.  I will check this out, and will try and download another copy meantime.

Actually, to that end I have a copy of a program named XClone.exe that runs in DOS and would probably do the job.  I will look at this, but the annoying thing is that I have used the Win98 xclone.exe many times before with no problems.

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 30

Assisted Solution

callrs earned 250 total points
ID: 16952809
>>My copies of XXcopy.exe and XXcopy16.exe don't seem to support
Download & re-install the latest version from
Let me know if that gives same problem...
The xxcopy /? WON'T tell you all the options.
xxcopy /help
xxcopy /help | more
xxcopy /helpa | more
(above 3 tips from
Or see the website
LVL 32

Expert Comment

ID: 16957245
<interested in seeing if Xclone copies from CD>
LVL 10

Accepted Solution

For-Soft earned 250 total points
ID: 16957745
xcopy G:\win98 D:\WIN98 /S /W will work without GUI in the clean DOS. Other switches are not available.
The help screen from XCOPY /? is different in clean DOS and with GUI loaded. Clean DOS XCOPY command supports less switches than the GUI one.

Looks like the XCOPY.EXE works only in clean DOS. With GUI loaded XCOPY.EXE runs the XCOPY32.EXE program and passes the parameters to it.
LVL 38

Author Comment

ID: 16957912
Thank you very much for that info and for the links, callrs.
Thankfully the new version has combined all the myriad of separate switches for accurate directory copying into one /CLONE switch (as you stated), and this is SO much easier to use ... and get right.  I'm still not sure why the Win98 XCOPY wasn't playing the game with me though.
XXCOPY16 worked perfectly using the following command from a batch file on a Win98se boot floppy:

xxcopy16  g:\win98\  d:\win98\  /clone

Add one additional switch to the ones you gave, and that is to output the program's return codes
xxcopy /helpe | more
xxcopy16 /helpe | more

In fact, the help file can be output to different formats as is obvious from the file names I have given in the following batch file to quickly create standalone help files:

@echo off
md docs
md docs\xxcopy_16_bit
md docs\xxcopy_32_bit
xxcopy /? > docs\xxcopy_32_bit\basic_syntax.txt
xxcopy /help > docs\xxcopy_32_bit\switches_by_function.txt
xxcopy /helpa > docs\xxcopy_32_bit\switches_alphabetic.txt
xxcopy /helpe > docs\xxcopy_32_bit\exit_codes.txt
xxcopy16 /? > docs\xxcopy_16_bit\basic_syntax.txt
xxcopy16 /help > docs\xxcopy_16_bit\switches_by_function.txt
xxcopy16 /helpa > docs\xxcopy_16_bit\switches_alphabetic.txt
xxcopy /helpe > docs\xxcopy_16_bit\exit_codes.txt

Thanks again.

For anyone else finding this PAQ'd question, here are a few important and interesting things that I found out about this excellent program.

The "switches by function" help file is the best one to read first, as it allows you to see how the switches interact with each other, and allows you to quickly assess which ones are relevant.

Useful Batch File Switches and How to keep prompts and other clutter safely off the screen:

Standard DOS Batch method of testing for existence/nonexistence of a folder:
if exist d:\backup\mybackup\nul goto :EXISTS
if not exist d:\backup\mybackup\nul goto :NOTFOUND

/IA   - Alternative XXCOPY internal switch as an alternative to "if not exist" while testing for folder existence in DOS
xxcopy c:\  d:\backup\mybackup\  /IA /clone
Checks for sub-folder named "mybackup" and, ONLY IF ABSENT, performs action.  Terminates immediately if it exists.

/IP   - Alternative XXCOPY internal switch as an alternative to "if exist" while testing for folder existence in DOS
xxcopy c:\  d:\backup\mybackup\  /IP /clone
Checks for sub-folder named "mybackup" and, ONLY IF PRESENT, performs action.  Terminates immediately if it exists.

Notes from help pages re Absolute and Relative Paths:

Differences between:
xxcopy c:\  d:\  /clone
xxcopy c:   d:   /clone

The first line of the above example explicitly specifies that both the source and the destination are the root directory of respective drives.
The second line does not specify which directory in the source and which directory of the destination within the respective drives.
That is, the second example above relies the exact location of both the source and the destination directories on the default behavior of the OS.  Microsoft's OSes keep track of the current (default) directory on each volume.  If it has not been defined yet, it will go to the root directory (which is what most users want).
Depending on the setting, when you open up a DOS box, the current (default) directory may or may not be at the root directory.  Also, the current directory of C: may be at c:\windows whereas on D:, it may be D:\.  You just cannot easily predict what it may be.  Therefore, the common assumption that an unspecified path is equivalent to the root directory is extremely dangerous with a tool like XXCOPY.

The consequence of the /ZY switch (which is part of the /CLONE switch) on a wrong source or destination could be FATAL (wipes out all mismatched directories along with their entire contents).


If you run the command:
cd  d:\mydir
the current directory of Volume D: will be set to d:\mydir.
So, unless you change the current (default) directory of Volume D: back to its root, when you say
xxcopy c:\  d: /clone
then, the line is equivalent to:
xxcopy c:\  d:\mydir  /clone

Similarly, when volume C:'s current directory is not at the root directory (it could be at c:\windows) and you try to copy:
xxcopy c:  d:\ /clone
In this case, it is equivalent to:
xxcopy c:\Windows  d:\ /clone
Again, it would give you quite a surprise.

More than one "current" directory:
With the most popular setting of the DOS prompt which usually shows you the "current directory of the current drive" such as the following:
You don't get any feedback on what is the setting of another drive.

For example, the same example shown above, as seen in the DOS window:
C:\WINDOWS> cd d:\mydir

When the cd (chdir) command succeeds, there will be no confirmation message that it has changed the current directory on the D: Drive to D:\mydir\.  The command is quietly accepted and executed.

Why XXCOPY does not supply the leading backslash for you?
The way the Absolute pathspec and relative pathspec are handled throughout the command line environment (be it DOS, Win32, or even Unix), the convention for the absolute pathspec and the relative pathspec are fundamental and ubiquitous.  If we were to implement XXCOPY's own convention and let XXCOPY implicitly supply the missing leading backslash, it would create chaos.

You must control the "current directory" from within a batch file.  In Windows (for all the 9x and NT families), every shortcut object comes with a setting of the "current directory" (Right-click on the icon and look for the "Start in" setting).  In a case of a program file or a batch file, the directory specified in the "Start in" setting becomes the current directory when the program is executed.  This is a common fault when a user uses the switch to output a log file, but it doesn't seem to have been created.  ALWAYS spell out the full filespec in the XXCOPY command.
xxcopy c:  d: /clone

The /CLONE switch is too dangerous to let the system default setting determine the fate.  Instead always specify the directory using the full (absolute) directory path:
xxcopy c:\  d:\  /clone

LVL 38

Author Comment

ID: 16958075
Hi coral47
I remember now that it was you who first made me aware of xclone:
"If the resize will not give you enough space, and there is a lot of free space on the main partition, I know a way to get it back.  Given that W9x/Me likes to lock certain file in place, you sometimes get a lot of open area in the C: partition.  I found that by using Xclone:
1. Copying to another HD
2. Formating the first
3. Then copying it back,
it tightened up the file spacing and let me have more room to resize the partition.
Note:  Xclone does not like the RESTORE functionality in ME, so I had to use a W98 system to clone the ME drive, though it might be OK if you Turn Off Restore in ME.
I have heard mixed results with NTFS drives, and it doesn't seem to like XP at all, due to some process XP has running.

I cannot report yet on whether it worked from CD, because I haven't tested it.  I intend to do so though, just out of curiosity, but I seem to recall reading somewhere in the readme files that it did not copy from CD in DOS because of the way the DOS CD-Rom Driver makes the drive accessible.  Perhaps I'm mistaken though, and it was one of the other programs archived on my system that I am thinking about.

I think you have struck the nail on the head with what you have said about the XCOPY32.EXE being automatically invoked when you run XCOPY.EXE from a DOS Box or batch file WITHIN Windows.  It's not something I have given any thought to before when I redirected the XCOPY32 and XCOPY help syntax to separate text files from a DOS Box and found them to be exactly the same, but it makes sense.  That's most likely the reason for XCOPY32.MOD.
Again, out of curiosity, I will try the command:
xcopy G:\win98  D:\WIN98 /S /W
and see what happens.

Long term, though, I think the versatility of XXCOPY16.EXE beats XCOPY.EXE.

Thank you all.
LVL 38

Author Comment

ID: 16958225
I've just done a binary comparison of Win98se's XCOPY.EXE and XCOPY32.EXE.
The *.exe files are EXACTLY the same, so it's just the *.MOD file that allows the extra support in 32-bit mode.
In fact, peeking into the textual content of the MOD file, I see where my error message was generated from:
Invalid switch -
LVL 10

Expert Comment

ID: 16958666

In Windows 95 both XCOPY and XCOPY32 are different files. Inside of the XCOPY.EXE file there is a visible text of XCOPY32.EXE file name.

Windows 98 has both XCOPY and XCOPY32 files the same, but the system remained. The difference is the name of the GUI file (XCOPY32.MOD).
LVL 32

Expert Comment

ID: 16965777
: D   I remember that thread. Cloning WinME was a real pain.

Nice info on the xxcopy.   : )
LVL 38

Author Comment

ID: 16966649
Another Aha!!  :-)

Re. coral47's query about whether XCLONE works with CD's as the source, I can confirm that it does.
I modified autoexec.bat on a Win98se boot floppy (no "RamDrive") and added a reloading menu so that I could test the following program versions one after each other:

XCLONE version 1.3
XXCOPY16 version 2.92.6
Win98se XCOPY (on its own without xcopy32.exe or the MOD file)

I used a different partition for each program so that I could keep the paths the same lengths and not cloud the results with any differences.  I also did it 3 times, reversing the order so that choked up memory wouldn't be a consideration.

xxcopy16 g:\win98\ d:\win98\ /clone
xclone g:\win98 e:\win98 /v
xcopy g:\win98 f:\win98 /s /w

The default behaviour of xclone is to verify files, and even with the verbose output switch ( /v), it still copied faster than Win98's xcopy.  However, the winner with sheer speed (even while displaying file copy progress on screen) was xxcopy16.  It also gave the most comprehensive warnings when trying to copy to an existing folder, and also good final result status.

Binary comparisons and verbose DIR listings of all 3 destination folders shows that, in the given scenario where long file names are not an issue, they ALL yield exactly the same results.

Thanks again, guys.
LVL 32

Expert Comment

ID: 16973899
That will make my life a little easier when I have to copy the .CAB files from the CD to a hard drive.
Thanks.   : )
LVL 38

Author Comment

ID: 16973944
No problem, coral.

One important thing I forgot to mention was that, BEFORE calling the programs from DOS, I loaded SMARTDRV.EXE from autoexec.bat.  Without that, all copying took longer than it took me to get into work yesterday evening.  The Eagles were playing at the national soccer stadium as part of their farewell tour, and my journey happens to be one of the main routes to the stadium.

In fact, load smartdrv (no switches) before doing ANY file copying in DOS.  That includes booting to DOS to install Windows XP from CD or folder on a hard drive partition, if that's your preference or only option.  The first time I did that the file copying took what seemed like a week and a half !
LVL 32

Expert Comment

ID: 16973976

>> The Eagles were playing... <<  Did you atleast get to hear them while you were in the traffic jam?
LVL 38

Author Comment

ID: 16974272
Nope.  The stadium is a bit away from the motorway , which is a pity.  One of the guys at work forked out several hundred bucks for a ticket, and I hope he isn't disappointed.  I would have thought the band members would have needed zimmers or walking sticks to get onto the stage by now :-)

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A Bare Metal Image backup allows for the restore of an entire system to a similar or dissimilar hardware. They are highly useful for migrations and disaster recovery. Bare Metal Image backups support Full and Incremental backups. Differential backup…
Learn how to PXE Boot both BIOS & UEFI machines with DHCP Policies and Custom Vendor Classes
As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

756 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question