Computer Hope
Microsoft => Microsoft DOS => Topic started by: rogerk8 on October 08, 2012, 03:55:07 PM
-
Hi!
I am trying to clone a small hard drive to a bigger one.
I refuse to use available software for this because I want to know what is happening.
And I love MS-DOS!
Today I tried to add xcopy.exe to a floppy start-disc which windows XP could generate for me.
The problem is that "the start-up floppy" generated "cannot run xcopy in DOS mode"
So I have searched the web for older versions of xcopy which do not use the "DOS emulation" but haven't found none.
I don't know the version of DOS of the start-discette but it is obviously an older one. And not windows XP based because it was there I first enconrtered the problem.
I refuse to pull out the both hard drives and put them in another computer just to copy c: to e:.
There's got to be a simpler way using xcopy from some unused drive.
I have understood the hard way that DOS cannot copy DOS itself so the copying has to be done via another drive (f.i A:).
But I do not understand why xcopy.exe couldn't be run from the start-up discette.
I do however understand that the DOS version of xcopy (and fdisk) will have to be compatible with used DOS from the primitive start-up discette.
It is amazing though that a finite space of 1.44MB could render any DOS functions whatsoever functionable!
If I don't get this to work I will have to move both drives (20GB+120GB) to another computer just to be able to copy C: to E:.
And when I'm done doing that, I will have to run fdisk /mbr just to create a Master Boot Record in the first sector of E:.
As it looks right now, this is what I will have to do,
Take care!
Best regards, Roger
-
I refuse to use available software for this because I want to know what is happening.
This is a stubborn approach at best...
Even if and when you do get xcopy to do this you will find it will not boot properly as it's not designed for the task...
Carry on...
-
Msdos versions of xcopy do not support long filenames.
There are scads of ways to clone a drive - a bootable cdrom and clone to a USB drive, is one.
Use the correct tool at the right time.
-
I am trying to clone a small hard drive to a bigger one.
This cannot be done with xcopy. Even if you could copy all the files, that isn't a strict clone.
I refuse to use available software for this because I want to know what is happening.
And I love MS-DOS!
The problem is that "the start-up floppy" generated "cannot run xcopy in DOS mode"
the xcopy program you run from within windows is a windows application, not a DOS one. the XP startup floppy is in fact a Windows ME startup disk. The appropriate version of xcopy would be found in C:\Windows\Command on a machine running Windows ME.
I don't know the version of DOS of the start-discette but it is obviously an older one. And not windows XP based because it was there I first enconrtered the problem.
Yep, answered that earlier in this post: XP creates a Windows ME startup disk.
I refuse to pull out the both hard drives and put them in another computer just to copy c: to e:.
There's got to be a simpler way using xcopy from some unused drive.
I have understood the hard way that DOS cannot copy DOS itself so the copying has to be done via another drive (f.i A:).
Aside from the technical fact that xcopy doesn't really "clone" drives, a DOS version of Xcopy, running within DOS, will be almost useless for copying a drive running Windows XP- or any NT variant. This is because by default those systems use a NTFS file system, which older versions of DOS (including the startup disk XP makes) cannot read or write, or even know exists. And even if it could, the xcopy'd files would not work either, since that drive would not have a boot sector.
But I do not understand why xcopy.exe couldn't be run from the start-up discette.
It's Windows console program. Not all programs that run at the command like are "DOS" programs. In fact, very few are.
If I don't get this to work I will have to move both drives (20GB+120GB) to another computer just to be able to copy C: to E:.
I've just used the included software provided with a new hard drive to copy it. Boot to the disc, partition to partition copy, wait, swap the drives, and reboot and I was rolling.
And I love MS-DOS!
Some might argue that this is a sign of mental illness ;D
I refuse to use available software for this because I want to know what is happening.
This is an odd requirement. At what level do you need to know this, and why? xcopy can show the files you copy, but that won't work the myriad of reasons described previously. the cloning tools provide a percent complete, which is really all you can expect since a proper clone tool has no knowledge of files or filesystems.
-
I would suggest using an Ubuntu live cd (see Ubuntu.com) and cloning the disk with DD
The command format is:
dd if=/dev/olddrivename of=/dev/newdrivename
You can find out your /dev/devicenames by opening a the disk utility. Note that if you do the command wrong you can lose all your data, so make sure you get it right! After you copy the data, you can use Disk Utility to "grow" the partition to use the entire drive. If you don't you'll be stuck with your old drive's capacity.
There's a decent tutorial on this at http://www.howtogeek.com/howto/19446/make-a-drive-image-using-an-ubuntu-live-cd/
-
Hi!
I have tried three stubborn approaches:
1) XP-generated DOS start discette (neither xcopy or fdisk was included. I included xcopy by a search, copy and paste...)
2) DOS 5.0 start discette
3) DOS 6.22 start discette
In case 1) I got "cannot run this program in DOS mode"
In case 2) & 3) I got "invalid drive specification"
I even tried to set c: as the active disk in the a: prompt but it echoed the same, i.e "invalid drive specification".
All I need is a working DOS program in a: which can run xcopy.exe c: e: /s
And I have tried and tried to make this happen.
With regards to 2) & 3) I think the problem is NTFS. E: is formated in NTFS. The discettes are however formatted in FAT...
I case 1) I can understand that the XP-DOS copied xcopy could not work because DOS is only emulated in later versions of Windows (XP).
The problem with 2) & 3) got to have to do with wrong file formats. It is the only way a newbie like me can explain it.
I have however understood that MS-DOS isn't free and that it seems like you actually can't use it.
The only way seems to be to move the disks to another computer, set both to Slave and use the (c:) xcopy from there.
The problem here is that the so called MBR (Master Boot Record) will not be copied.
But if I reattach the larger disk to my original computer, I can run fdisk /mbr there generating a MBR on this system disk. Because I have understood, from Microsoft's homepage, that a MBR can only be created on the system disk (disk 0).
Tomorrow I will check if fdisk.exe is available in my XP-DOS which I hope. But in review of another forum, I can actually copy & paste MBR to this new system disk using a hex-editor. But let's hope I don't have to do it in this kind of complicated way.
Take care you all!
Best regards, Roger
-
Did you actually read any of the info above ? ?
-
This basically comes down to what everyone else has already said. Use the right tool to do the job. You are not using the right tool. You are trying to use a tack hammer when the job really requires a much bigger hammer.
-
1) XP-generated DOS start discette (neither xcopy or fdisk was included. I included xcopy by a search, copy and paste...)
Doesn't work for reasons stated above. WinXP does not have the xcopy, or any MS-DOS executable, designed to run on MS-DOS 8 (which is the version that ME identifies as).
2) DOS 5.0 start discette
3) DOS 6.22 start discette
DOS versions before Windows 95OSRB only understand FAT, and cannot read (without third party software) either FAT32 or NTFS partitions. These show up as "Non DOS" partitions and you cannot read them and they are not assigned drive letters.
In case 1) I got "cannot run this program in DOS mode"
The xcopy program you copied is a Windows 32-bit console application.
In case 2) & 3) I got "invalid drive specification"
Plain DOS does not understand FAT32 or NTFS, one of which (probably the latter) is the File system you are using.
I even tried to set c: as the active disk in the a: prompt but it echoed the same, i.e "invalid drive specification".
DOS cannot mount a drive whose filesystem it does not understand.
All I need is a working DOS program in a: which can run xcopy.exe c: e: /s
You are not going to find one.
And I have tried and tried to make this happen.
Some people define insanity as trying the same thing repeatedly and expecting different results. :P
With regards to 2) & 3) I think the problem is NTFS. E: is formated in NTFS. The discettes are however formatted in FAT...
The problem is that NTFS is not understood by any of the boot disk versions of DOS. the ME version (DOS 8) understands FAT32, but none of them support NTFS and those appear to it as completely foreign partitions.
The problem with 2) & 3) got to have to do with wrong file formats. It is the only way a newbie like me can explain it.
Incorrect Filesystems, but yes.
The only way seems to be to move the disks to another computer, set both to Slave and use the (c:) xcopy from there.
That will not work either.
The problem here is that the so called MBR (Master Boot Record) will not be copied.
The problem is that the computer you connect it to will not have read access to a good portion of the drive. Due to the Access Control list. If you want to clone a drive, use a tool designed for copying partitions, not copying files.
But if I reattach the larger disk to my original computer, I can run fdisk /mbr there generating a MBR on this system disk. Because I have understood, from Microsoft's homepage, that a MBR can only be created on the system disk (disk 0).
This won't work. You cannot access NTFS partitions from the boot disks you have. fdisk /mbr will only work on a mountable, formatted drive, and it will write a DOS MBR, rather than a Windows NT MBR.
Tomorrow I will check if fdisk.exe is available in my XP-DOS which I hope.
It's not. Windows NT uses "diskpart" for command prompt editing of partitions.
But let's hope I don't have to do it in this kind of complicated way.
You are the one insisting on doing so. As me and several others have said, there is software available for free that does exactly what you want. Instead of accomplishing your goal in a mere hour, however, your insistence on not using that software for ad-hoc reasons has left your problem unresolved for several days.
I do understand what you are doing- you are doing what you would have done with a DOS system. xcopy the drive with a sys command was usually enough to get it working. That is not the case. It hasn't overall become more complicated user-side if you use the proper tools.
-
Hi!
Thank you all!
I especially want to say thanks to you BC_programmer. How much work didn't you put in just to answer my stupid questions? It was very interesting and educational. Thanks!!
Today I finally tried a cloning program (clonemaxx). It didn't work. It obviously didn't like SCSI-drives which I was amazed to found out that the primary drive was. The other was an IDE (and that one the cloning program found but not the primary one).
Then I thought I was really unlucky with this project of mine.
The idea to move the disks to another computer, put them in slave mode and use the C: to copy the drive thereby got smashed. This is because it seemed unlikely that another computer would support both SCSI and IDE.
Then my bright friend and collegue told me that you actually can install programs on e: and thereby stop using c:. With exception of the slight problem of windows by default wanting to store things on c: this has actually become my solution!
Because let's face it, why do we want to clone a hard drive?
Isn't it because of some semi-illegal purpose of copying all programs on a hard drive to be used in another computer (too)?
If the statement that it is possible to install programs on another physical disk is true, then it is actually pointless with cloning!
I have already made up my mind that I will move those folders which I know is movable to e:. And perhaps I will even move Documents & Settings. My friend showed me that you can actually order windows to do that. I think I will do it that way because hopefully windows will remember where the folder is (so that I do not have to change path everytime).
As you can see above, the problem with a full drive, is academic!
Cloning is pointless! :D
Take care!
Best regards, Roger
-
Because let's face it, why do we want to clone a hard drive?
It's usually known as a backup.
-
Because let's face it, why do we want to clone a hard drive?
One very good reason would be because of buying a new hard drive (e.g. to replace one that is too slow, too small, or unreliable). Another would be to make a standardised OS and software installation for deployment in an organisation.
Isn't it because of some semi-illegal purpose of copying all programs on a hard drive to be used in another computer (too)?
No.
-
Hi!
I take back my stupid conclusion. Is this possible? :D
One thing I have discovered for myself is that my "solution" will not work for laptops.
I appreciate you guys telling me that I was wrong and explained what I was wrong about.
To summarize, cloning is (almost) neccesary when it comes to:
1) Replacing a full laptop drive (no space within for yet another drive)
2) Replacing an old drive (and perhaps even a slow one)
3) Replacing a full ordinary drive (here windows however warns you when available disk space is less than some 500MB...)
4) Making a standardised OS and software installation for an organisation (very good point)
5) Making a simple backup (also a good point)
I rest my case ;)
Finally I want to tell you that I tried cloning one final time today (because even I understand the benefits). The cloning program (Easyus) worked very well. It was just that my Compaq Evo W6000 actually had two types of dives. One SCSI and one IDE. And somehow the hardware preferred that C: should be a SCSI drive. I tried lots of things (including master jumper) but only got "read error" when I tried to boot from the cloned IDE drive.
So today I have given up and actually managed to free 1GB from C:(20GB) by moving knowingly movable folders to E:(120GB). It is my humble hope that this will last some 10 years more (because all data and installations will from now be stored/done in E:).
I thank you for all the help!
Best regards, Roger
PS
I have actually experiensed 4) in the real world. It was when I worked for a very large tele-com company here in Sweden.
-
Would this work?
xcopy c: e: /s /exclude c:\windows
8)
-
Would this work?
xcopy c: e: /s /exclude c:\windows
8)
To clone your hard drive? No! It would never be bootable and you wouldn't want to try and backup the page file.
-
Not to clone, just to copy.
Is the syntax alright, then?
Just curious.
;)
-
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.
-
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 :D
-
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
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 :D
It works for me:
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...
I rest my case ;)
-
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.
-
His quote...not mine.
But point well taken.
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 :D
Take care!
Best regards, Roger
PS
Thanks for "I rest my case" (if I understand english correctly...)
-
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.
-
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.
-
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 :D
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
-
Please excuse me for being so stubborn :D
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 /?