There is no simple answer, but here goes. We're sure that if you watch the newsgroups, or in other places around the Internet you have seen many methods for the use of XCOPY offered. Many of these solutions offer XCOPY with a number of command line options, say it works, and leave it at that. It's not their data, what do they care if the method works for you, or you lose all of your data? You might say "Well don't these guys writing this make a replacement for XCopy?", Yes we do, however, if we thought that there was a method that worked we would tell you, and why would we have spent thousands of hours in development time to make a program that was already included in Windows?
This has been tested on All Windows. All possible command line switches have been tried to resolve issues presented here. Oh, just forget about trying xcopy with Windows 2000, XP, Vista, or Windows 7. Xcopy may work with data (information presented here taken into consideration), but never for database files or operating system files.
What you may have missed in many of these conversations is that very often a person will post "I used XCOPY and all went just fine." only to find that the same person will post later saying "What the heck, this worked before why won't XCOPY work this time." or "what happened?", or worse yet they don't post again and have serious problems.
There are four basic reasons why XCOPY fails.
1). XCOPY does not preserve file or directory attributes.
2). XCOPY does not preserve time and date stamps on directories.
3). XCOPY does not warn you of files unable to be copied.
4). XCOPY does not keep the SFN (Short File Names) aliases from
being mangled.
Numbers 3 and 4 from above is the most serious and most frustrating problem to see the effects of until it's usually too late. Point 3 because /C must be included. When files are missing you wont know until they are requested. Remember that the =Registry= uses SFN's not LFN's (Long File Names). Here are examples (Proof) you can try to see this problem in action. This will require some knowledge of DOS.
First we will create some directories.
Enter the following at the command prompt:
C:\> MD test (Enter)
C:\> CD test (Enter)
C:\test\> MD "This is a long directory name A" (Enter)
C:\test\> MD "This is a long directory name B" (Enter)
C:\test\> MD "This is a long directory name C" (Enter)
This will create the following SFN (Short File Name) output:
THISIS~1 <DIR> This is a long directory name A
THISIS~2 <DIR> This is a long directory name B
THISIS~3 <DIR> This is a long directory name C
Now lets create some files in our example:
Enter the following at the command prompt:
C:\test\> COPY CON "This is a long file name A.txt" (Enter)
...TEXT... (Ctrl Z)(^Z)
C:\test\> COPY CON "This is a long file name B.txt" (Enter)
...TEXT... (Ctrl Z)(^Z)
C:\test\> COPY CON "This is a long file name C.txt" (Enter)
...TEXT... (Ctrl Z)(^Z)
This will create the following SFN (Short File Name) output (DIR)
THISIS~1 <DIR> This is a long directory name A
THISIS~2 <DIR> This is a long directory name B
THISIS~3 <DIR> This is a long directory name C
THISIS~1 TXT This is a long file name A.txt
THISIS~2 TXT This is a long file name B.txt
THISIS~3 TXT This is a long file name C.txt
Notice the correlation between the creation order of both the directories and files and their corresponding LFN (Long File Names) to SFN aliases. (~1, ~2, ...).
If we were to copy the TEST directory right now using XCOPY or any other program the naming would be preserved. But this is not yet a real world example, and we are not dealing with system files here remember. The Windows registry maintains thousands of references to the SFNs, and when these are EXE, VXD, DLL, or any other binary system or application support files, mangling the SFNs can be a system crash waiting to happen. In the course of updating or installing new software to your system over time this pristine naming example from above will be mangled.
Lets do some name mangling:
Enter the following at the command prompt:
C:\test\> RD THISIS~2 (Enter)
C:\test\> DEL THISIS~2.TXT (Enter)
Now the output (DIR) will look like this:
THISIS~1 <DIR> This is a long directory name A
THISIS~3 <DIR> This is a long directory name C
THISIS~1 TXT This is a long file name A.txt
THISIS~3 TXT This is a long file name C.txt
Lets copy the TEST directory using XCOPY to see what happens
Enter the following at the command prompt:
C:\test\> XCOPY *.* C:\test1 /e (Enter)
C:\test\> CD\ (Enter)
C:\> CD test1 (Enter)
The new TEST1 directory output (DIR) will look like this:
THISIS~1 TXT This is a long file name A.txt
THISIS~2 TXT This is a long file name C.txt
THISIS~1 <DIR> This is a long directory name A
THISIS~2 <DIR> This is a long directory name C
You can see the problem immediately, XCOPY has reassigned the ~3's to ~2's. You can imagine the kind of problems this would cause if these where system or application files. This is only the tip of the iceberg. This large error in conjunction with points 1, 2, and 3 from above make for system crash and possible loss of data just waiting to happen. If you use the XCOPY method for copy or backup you could consider yourself one of the lucky ones if the system blows from the first boot. Those who are not so lucky might not find out about these problems until there original drive has been formatted and sold. Watch for commercial programs as well.
The long and short of this is "How valuable is your data, is it worth risking" only you can make that decision. Do you feel lucky?