XCOPY giving Invalid Switch error

>>/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

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).

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.

Thanks
Bill

<interested in seeing if Xclone copies from CD>

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
exit

Thanks again.
Bill

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

NOTE:
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:
---------------------------------------------------------------------------------------------------------
http://www.xxcopy.com/xxcopy19.htm

Standard DOS Batch method of testing for existence/nonexistence of a folder:
if exist d:\backup\mybackup\nul goto :EXISTS
or
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:
---------------------------------------------------------------
http://www.xxcopy.com/xxcopy22.htm

Differences between:
xxcopy c:\  d:\  /clone
and
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).

Examples:

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:
C:\WINDOWS>
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
C:\WINDOWS>

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.
 
NEVER USE A SLOPPY COMMAND LINE LIKE THIS:
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

Hi coral47
I remember now that it was you who first made me aware of xclone:
https://www.experts-exchange.com/questions/21276756/change-partition-size.html
>>>
"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.

For-Soft:
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.

Aha!!
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:
F D
Invalid switch -
%1

Curious.

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).

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

Nice info on the xxcopy.   : )

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.

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

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 !

Noted.

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

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 :-)