Saved Bookmarks
| 1. |
Solve : Small hard drive cloning? |
|
Answer» Not to clone, just to copy. Is the syntax alright, then? No- from xcopy /?: Quote /EXCLUDE:file1[+file2][+file3]... 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. 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 Quote from: rogerk8 on October 17, 2012, 11:30:53 AM And if I understand it correctly, the syntax (i.e order of switches) is still correct except for the specification of the excluded files.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. Quote Reading the xcopy help tells me that it is actually possible to run:/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 Quote 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. Quote 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> My absolute favorite Quote of this entire 2 page Topic is from the topic starter... Quote I rest my caseQuote from: patio on October 17, 2012, 04:40:44 PM 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.His quote...not mine. But point well taken.Quote from: patio on October 17, 2012, 06:22:57 PM His quote...not mine. Sorry, I was referring to it's use elsewhere.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...)Quote from: rogerk8 on October 18, 2012, 01:35:52 PM Have I understood you correcly BC_Programmer that if I just put the actual expression xcopy C:\*.* E:\ /exclude:\excluded.txt would likely be what you want.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. Quote from: rogerk8 on October 18, 2012, 02:24:04 PM 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.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, RogerQuote from: rogerk8 on October 18, 2012, 03:32:13 PM Please excuse me for being so stubborn No. type this in a CMD prompt to find out why: xcopy /? |
|