Small hard drive cloning

[rogerk8]

Not to clone, just to copy.

Is the syntax alright, then?

Just curious.

 

[BC_Programmer]

Is the syntax alright, then?

No-

from xcopy /?:

/EXCLUDE:file1[+file2][+file3]...
             Specifies a list of files containing strings.  Each string
             should be in a separate line in the files.  When any of the
             strings match any part of the absolute path of the file to be
             copied, that file will be excluded from being copied.  For
             example, specifying a string like \obj\ or .obj will exclude
             all files underneath the directory obj or all files with the
             .obj extension respectively.

So if you wanted to exclude the windows directory, you would need to put \windows\ in a separate text file, and specify that text file to xcopy.


FWIW this probably wouldn't work. Many files in the User profile are opened exclusively by windows (such as the registry data files), in addition to programs themselves having locked files*, as well as things such as the "System Volume Information", which will cause a permission error when xcopy tries to inspect it. Possibly the same story with the pagefile (which would be pointless to copy anyway). You can probably make a good sized text file, just with the list if necessary exclusions.


*It is a common misunderstanding that a program having a file open prevents it from being copied. It is fully possible for programs to open files in a shareable manner, but some programs are written lazily; essentially when opening the file the program has to say what other programs can do with it (read, write, delete, etc). If the program doesn't say anything about it, Windows takes the safe route and locks the file for the duration of the time the program has it open, and prevents other programs from accessing it.

[rogerk8]

From typing "help xcopy" in the XP-DOS prompt I got the same result (lazy of me).

But I like your answer.

And if I understand it correctly, the syntax (i.e order of switches) is still correct except for the specification of the excluded files.

But why would I need to put \windows\ in a separate text file? I don't even understand what you mean by this.

Reading the xcopy help tells me that it is actually possible to run:

xcopy c: e: /s /exclude \windows\

Because windows already is a root directory.

Best regards, Roger
PS
While I was testing and learning about xcopy I discovered a fantastic thing. You were actually able to copy an open file! And windows sucks when it comes to that kind of simple and good features. When I discovered this I naively thought that it also could copy itself 

[BC_Programmer]

And if I understand it correctly, the syntax (i.e order of switches) is still correct except for the specification of the excluded files.

But why would I need to put \windows\ in a separate text file? I don't even understand what you mean by this.

the /EXCLUDE switch is documented in /?- it specifies a list of files containing strings. The rest of the paragraph describes the format of the text file as well as how the strings within the file will be parsed and compared with each filename. eg. "When any of the
strings match any part of the absolute path of the file to be
copied, that file will be excluded from being copied.  For
example, specifying a string like \obj\ or .obj will exclude
all files underneath the directory obj or all files with the
.obj extension respectively." is referring not to the strings provided on the command line, but rather how strings should appear in the text files specified in the /exclude switch.

Reading the xcopy help tells me that it is actually possible to run:
xcopy c: e: /s /exclude \windows\
Because windows already is a root directory.

/exclude is documented as accepting text files that contain strings, not the strings themselves. using the above will likely give you a message of the sort

Code: [Select]

Can't read file, \windows\

0 File(s) copied


And windows sucks when it comes to that kind of simple and good features.

It has nothing to do with Windows itself. When an application opens a file, it is supposed to specify a "Share mode"; that is, how other programs can use that file while it's open. (whether other files can read, write, or delete it are separate, so a program could lock file writes but allow other programs to read the file while it has it open). If the program opens a file but doesn't specify a share mode, Windows decides that caution is the better part of valour and prevents Reads, Writes, and Deletes, effectively locking the file until the application closes it.

Another interesting point: some people occasionally have issues where Explorer.exe keeps a file open. This is not, however, Windows Explorer that is keeping the file open, but rather "Shell Extensions" which explorer loads. The result is that the shell extension, usually installed as part of a third party program, will open the file, but not specify a share mode, so the file get's locked; and then it never closes it. The result is that Explorer (which is the associated process) get's blamed. It's not really a bug in explorer, but a bug in an extension.

When I discovered this I naively thought that it also could copy itself 

It works for me:

Code: [Select]

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Windows\system32>xcopy xcopy.exe C:\xcopy.exe
Does C:\xcopy.exe specify a file name
or directory name on the target
(F = file, D = directory)? F
C:xcopy.exe
1 File(s) copied

C:\Windows\system32>


[patio]

My absolute favorite Quote of this entire 2 page Topic is from the topic starter...

I rest my case 

[BC_Programmer]

My absolute favorite Quote of this entire 2 page Topic is from the topic starter...

resting one's case before putting forth the arguments that make it is an effective debate strategy. As long as nobody notices, I suppose.

[patio]

His quote...not mine.
But point well taken.

[BC_Programmer]

His quote...not mine.
But point well taken.

Sorry, I was referring to it's use elsewhere.

[rogerk8]

Have I understood you correcly BC_Programmer that if I just put the actual expression

\windows\

in a text file f.i called

excluded.txt

and store this in the root

I could run

xcopy c: e: /s /exclude \excluded.txt\

?

Actually, the number of folders in the root seldom are that many so you can actually copy them manually without that much of an effort 

Take care!

Best regards, Roger
PS
Thanks for "I rest my case" (if I understand english correctly...)

[BC_Programmer]

Have I understood you correcly BC_Programmer that if I just put the actual expression

\windows\

in a text file f.i called

excluded.txt

and store this in the root

I could run

xcopy c: e: /s /exclude \excluded.txt\

xcopy C:\*.* E:\ /exclude:\excluded.txt would likely be what you want.

[rogerk8]

One final time.

While you indirectly have told me that the syntax in excluded.txt is right I could actually run:

xcopy C:\*.* E:\  /exclude: \excluded.txt

This is amazing!

Thank you very much!

Best regards, Roger
PS
The above command will then actually give me a simple backup. Without the commonly believed necessity of cloning.

The fun thing now is that you are still able to "clone" if this is what you prefere.

In that case, you should however make use of your (windows) istallation CD BEFORE the above.

Please tell me that I have understood this correctly.

[BC_Programmer]

The above command will then actually give me a simple backup. Without the commonly believed necessity of cloning.

I already mentioned some reasons this wouldn't work. It won't copy any hidden or system files (though that probably isn't desired) and it will encounter Permission errors trying to copy the registry data files in the active user profile. ANother common XCOPY problem when copying lots of files is that it encounters a Insufficient Memory error, which may be in part traced to longer file names (or possibly it creating lists of files to copy, or something to that effect).

Another option worth considering, if you insist on this methodology of using a batch file, might be Robocopy. I don't think it comes with XP, but if memory serves it is available through the windows Resource Kit.

[rogerk8]

Please excuse me for being so stubborn 

This is nowadays almost academic, but I am still curious.

If I use XP-DOS and have enabled all hidden files to be visible the above command will work, or will it not?

You don't have to answer this. It has no relevance anymore. People could just copy their visible root-folders by hand.

But it would be nice with a simple command to do that for you.

Thank you anyway for answering!

Best regards, Roger

[foxidrive]

Please excuse me for being so stubborn 

If I use XP-DOS and have enabled all hidden files to be visible the above command will work, or will it not?

No. 

type this in a CMD prompt to find out why:

xcopy /?