[<<]Message[>>] [<<]Author[>>] Subject[>>] [<<]Thread[>>]
Number : 614 Date : 2001-08-19 Author : Dan Anderson Subject : Re: What Happened ? - MBR or shared file contention? Size(KB) : 13
Dude and Shep, The suggestion of a corrupt MBR seemed reasonable to me, particularly in light of the disk clean-up and defrag etc., and the fact that sometimes hardware can simply malfunction, although I have one other suggestion (4th paragraph). I was trying to understand why Dude thought there was a bug in xxcopy. I couldn't follow the reasoning and maybe you could elaborate on the problem that you had. I looked back at Dude's prior posting (under superdude) but the earlier issue seemed to be one of small variances in the time stamp which has been discussed at length but does not seem to be an operational issue in terms of the functioning of the operating system. Time stamps seem to be more of a convenience factor in deciding whether two files are identical and therefore a re-copy is not needed. Shep has already determined that an xxcopy clone can reboot cleanly, and the non-reboot problem was encountered only when he attempted to re-use the problem disk (and even that was okay once it was reformatted). However, the approach that Dude described where the windows subdirectory is cloned, under DOS, to a separate subdirectory and then renamed back to windows could solve any shared-file problems that might be encountered when running xxcopy under windows. Is this a likely source of problems?? The extent to which files are identified as shared may be a function of what other applications are running when the xxcopy is done, or applications that were run prior to xxcopy being run, but shared-file contention can supposedly happen simply because windows is running. If shared files are not copied by xxcopy (?) perhaps a critical file could be lost? I have not encountered those problems possibly because I use xxcopy in three specific ways: a) I xxcopy the primary partition on my laptop to my desktop computer over a direct-link network and run xxcopy from the desktop so that there are no shared-file contentions, b) for primary partitions on my desktop I can use partition magic to copy the primary partition to a logical partition and then can run xxcopy to copy the contents to a CD (in which case I would use DOSLFNBK to retain the LFN-SFN information), and again there would be no shared file contentions and c) I use xxcopy to clone logical partitions where there is normally no shared-file issue. If the issue of shared files is not a likely source of the problem then I would think the likely culprit is the mbr rather than any sort of time stamp issue with xxcopy. One caution with regard to the approach of using FDISK /MBR. My understanding is that the fdisk /mbr command will actually corrupt the master boot record if a person is using bootmagic for dual-boots. I think bootmagic has it's own option for recovering a backup of the mbr. Whenever fdisk /mbr is proposed as a solution it might be good to include the caveat (unless using bootmagic). ...Dan ============================== ----- Original Message ----- From: shep sweeney To: Sent: Saturday, August 18, 2001 1:41 PM Subject: Re: [xxcopy] Re: What Happened ? > Don, > Your approach sounds real good and it should work. > However, I think mine should have worked in the > same manner in that I changed my good D drive to > the C drive and then xxcopy C:\ D:\ /clone. As you > know xxcopy can copy all of windows and everything > else to the D drive with no problem. Then, I switched > the D drive back to becoming the C drive which > should have made the C drive equal to the good D > drive but for some reason it didn't. I think your idea > of a date stamp has something to do with it and that > may be the key. I think I remember xxcopying the > C to D (after switching master and slave) twice and > I think the second xxcopy actually copied 2 or 3 > files. It should have copied none as the first xxcopy > showed no errors. Maybe the answer is to use the > clone with a switch which will ignore the date stamps. > Does anyone know what that switch might be ? > Shep > ----- Original Message ----- > From: Dude > To: xxcopy@yahoogroups.com > Sent: Friday, August 17, 2001 11:09 PM > Subject: [xxcopy] Re: What Happened ? > > > Shep Sweeney, > > I don't agree with the assessment that your MBR is somehow corrupt. > I have had a problem with the /clone function much similar to yours > and have developed a work around for it. I posted my trouble but > never did get a direct answer. I let it die because the work around > WORKS. > > Here's what I have to do in order to get a clean copy of Windows from > a /clone backup. I enter xxcopy /clone d:\windows c:\winnew...Then I > close down to a pure DOS session and rename Windows to Winold Then > rename winnew to windows. It always works like a champ. Then of > course, delete the winold directory. > > I think that for some obscure reason the /clone switch sometimes > doesn't perform as it should and the bug needs to be tracked down. I > think it has to do with the time stamp of the backup files being > older than the destination files. Perhaps cloning from a backup > isn't a good restore method and we must use some other switch combo. > > Although my case wasn't exactly like yours, I think it failed for the > same reason. I was basically trying to accomplish a restore from dos > using xxcopy16 first and then booting to Windows on the copy that it > produced. Then I ran xxcopy in windows thinking it would delete all > the fractured long filename files that xxcopy16 produced. It didn't > work and I still don't know why. :( Fractured file names most > certainly didn't exist in the source and that supposedly fits the > criteria for deletion by the /clone switch. It did however copy the > correct named files also. That gave me a pretty fat system so I had > to manually delete the files with ~ in them using a FIND ~ > SELECT > ALL and delete. > > I posted my Iliad and Kan suggested I use XXCOPY d:\backup\ c:\ /s /nl > but I haven't tested that yet. > > I hope this helps you in some way. Good luck. > > Don > > > --- In xxcopy@y..., "shep sweeney" wrote: > > Kan, > > I think I see what you are saying and I had already > > made your special boot to win98 floppy but forgot > > to use it. > > In this case after I xxcopied the good drive (D:\ after > > making it the master) to my bad C:\ drive (after making > > it the slave) I do not know how the MBR could have > > gotten screwed up as xxcopy never touches the mbr. > > As I then switched the C:\ drive back to being the > > master, the system did boot up to the last screen in > > windows just before the desk top appears and then > > said Explorer caused a fatal exception. If this indicates > > a bad mbr, somehow I must have screwed it up when > > I was deleting files and generally cleaning up and defragmentimg > the C:\ > > drive just before this happened. > > Do you know how one can screw up the mbr (just so > > I can avoid doing it in the future) ? And a final question > > "Would it be better to just run Fdisk/mbr in this case > > since I had just xxcopied this drive from a bootable > > drive which would have copied the iosys and every- > > thing else ? Thanks for your help > > Shep > > ----- Original Message ----- > > From: Kan Yabumoto > > To: xxcopy@y... > > Sent: Friday, August 17, 2001 12:29 PM > > Subject: Re: [xxcopy] What Happened ? > > > > > > > > Shep: > > > > My first guess is that the boot sector (the first sector of the > > active partition) was not initialized right. Actually, in the > > current version of the /CLONE technical bulletin (XXTB #10), > > one case is omitted that is to initialize the boot sector. > > This can be done by the SYS.COM command. > > > > If you have problem booting up from the /CLONEd drive (done > > by XXCOPY), you should try "SYS C:" once. > > > > Here's why. > > > > The boot sequence of Win9x (and WinNT/2000) is as follows > > > > 1. The Primary DOS Partition of the first drive must be > > active. This can be done by running FDISK. > > > > 2. The master boot record (MBR) need to be set right. > > (the MBR is the first sector of the entire disk) > > This can be done by running "FDISK /MBR". It wil > > initialize the first 446 bytes of the MBR which is > > called "Master Boot Code" (the remaining 64 bytes > > are used for four entries in the partition table > > (16 x 4) and 2 checksum bytes) > > > > 3. When the boot sequence reads the MBR (by the BIOS > > code), and loads the master boot code into memory > > and run. It will reads the Boot Sector (the first > > sector of the active partition) into memory and > > executes it. The boot sector for DOS and Win9x > > is different from that for WinNT/2000/XP. The > > boot sector's code will search for the C:\IO.SYS > > file in the partition and executes, in the case of > > Win9x. On the other hand, if the partition is for > > WinNT/2000/XP, it will look for the \NTLDR file > > and executes it. > > > > Under normal circumstance where the disk has been > > formatted at least once by the FORMAT.COM program > > supplied by DOS/Win9x, then, it initializes the > > boot sector (the first sector of the partition). > > The equivalent action can be done by the SYS command > > (which will also copy the IO.SYS, MSDOS.SYS, > > DRVSPACE.BIN, and COMMAND.COM file). In a rare > > case, when the boot sector has been damaged, the > > /CLONE sequence described in our XXTB #10 is not > > enough because it does not tell you to run the > > SYS program ---- we left it out because we felt > > that once you do this, a dual-boot disk which was > > to run NT/2000/XP will no longer able to perform > > the dual-boot function. Probably, we should mention > > this in the article. > > > > 4. Once IO.SYS is loaded, it will look for the MSDOS.SYS > > file which declares the system drive (can be D:, E: > > or any other partition where the actual \WINDOWS > > directory resides). > > > > 5. It will then read the CONFIG.SYS file which optionally > > declares where to find the COMMAND.COM file (usually > > in the system drive (which could be D: or E:). > > > > 6. The COMMAND.COM program will then read and execute > > the \AUTOEXEC.BAT file from the partition where the > > boot sector was originally read. > > > > What I recommend to everybody who runs the Win9x system > > is to create a quick-boot diskette which will allow you > > to boot the win9x system from the floppy disk regardless > > of how the MBR and/or the boot sector is set up. > > > > Here's how: > > > > 1. Format diskette as the system disk > > > > format a:\ /s /u /f:1.44 > > > > 2. Copy the MSDOS.SYS file which is usually found in > > the root directory of C: drive into the floppy> > > > > xxcopy16 c:\msdos.sys a:\ /h /r /y > > > > If you find the following line in the file, > > > > Disablelog=0 > > > > You should edit it to read as > > > > Disablelog=1 > > > > Otherwise, the boot up process from the floppy will be > > painfully slow as the log file will be created on the > > floppy disk. > > > > 3. If you have CONFIG.SYS and AUTOEXEC.BAT, you should > > also copy them into the floppy. > > > > xxcopy16 c:\config.sys a:\ /h /r /y > > xxcopy16 c:\autoexec.bat a:\ /h /r /y > > > > This floppy will boot up much quicker than the so-called > > Emergency-Boot-Disk (EBD) which Win9x lets you create. > > > > Actually, using this technique, you can have a Win9x system > > which can boot up without reading any files in the root > > directory. All necessary files will be read either from > > the floppy disk and the system directory which can be > > D: or E:. On the other hand, if you try to boot up the > > system from the hard disk, the first partition's root > > (C:\ has to have the IO.SYS, MSDOS.SYS which belongs to > > the Windows version even if the system directory is in > > D: or E: --- which is the reason why you can't have more > > than one Win9x OS on one machine without using this floppy > > boot technique or to resort to SystemCommander which > > renames the files in the c:\ root directory). > > > > Kan yabumoto > > ============================================================= > > > > At 2001-08-17 14:35, Shep Sweeney wrote: > > >While I was cleaning up mt C:\ drive to get ready to > > >transfer it to a new Athlon system, I somehow got > > >the infamous "Explorer caused a fatal exception OE" > > >and the machine froze. > > >As I had a complete XXCOPY backup on the D:\ > > >drive, I switched the D:\ drive to the Master and the > > >bad C:\ drive to the slave. > > >The system immediately started up with nothing > > >wrong. As I wanted to switch back to my large > > >disk, I then XXCOPY C:\ D:\ /clone thereby > > >transfering my working drive back to the bad one. > > >I then switched back master and slave drives and > > >restarted the machine. Once again I had the same fatal > > >exception. > > >I then compared the two disk drives, they were > > >identical. After switching drives back and forth, > > >there was no way the original C:\ drive was going to > > >boot up. > > >I finally got the C:\ drive up by using MAX Blast plus > > >to reformat the C:\ drive and create a disk image of > > >D:\ on C:\. > > >Question is "Why did not the XXcopy clone do the > > >job? > > > Thanks for any help you can give me on this subject > > > > > > Shep > > > > > > Yahoo! Groups Sponsor > > > > > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > > > ---------------------------------------------------- > > NetZero Platinum > > Sign Up Today - Only $9.95 per month! > > http://my.netzero.net/s/signup?r=platinum&refcd=PT97 > > > Yahoo! Groups Sponsor > > > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. > > ---------------------------------------------------- > NetZero Platinum > Sign Up Today - Only $9.95 per month! > http://my.netzero.net/s/signup?r=platinum&refcd=PT97 > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.