[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 565 Date : 2001-08-09 Author : Kan Yabumoto Subject : Re: cloning and restoring from Size(KB) : 8
Don, Sorry, it became quite long but please bear with me. Since the Windows boot up process is a complex operation, it takes many steps to succeeds. Therefore, there are many places to go wrong and we need to address that many issues to correct the situation. ------------- The DOS-level restore operation from the D: drive should be really a last resort thing even when the system does not boot. The first thing you should do is to revert to the system registry of a few days ago (Yesterday's copy usually works quite well). (the details are given below). If the restoring the key files does not work, then, you should do the "hot restore" where you are trying to modify the Windows system files (many of the system executable and DLL files are write-blocked so that you just cannot restore them even from a DOS Box. It has to be the real DOS. In this case though, you will lose long filename (LFN). Don's solution was to use XXCOPY16. My suggestion is to get into the Win32 environment first (even in the safe mode if you can), and run XXCOPY.EXE to restore as many files as you can, ignoring the fact many files fails (but, more importantly, many may more files will be successfully restored). Now can you enter the Windows GUI environment --- Win32, when you can't boot? A good question. My suggestion is to create a special "Windows Quick Boot diskette" (different from the standard Emergency Boot Disk from Microsoft). You can do this all from the pure DOS level --- command-prompt-only. You can easily make one by the following steps (while you have a stable Win9x environment). 1. format a: /s // create a bootable diskette 2. xxcopy c:\msdos.sys a:\ /h/r/ks/y 3. xxcopy c:\config.sys a:\ /y 4. xxcopy c:\autoexec.bat a:\ /y (For WinME, you need to change this a little). This diskette is very handy. What it does is to allow the booting process without accessing any file in the C: drive (root directory) at all. All it uses are the files in the diskette and the c:\windows directory. This technique is also useful when you want to create another version of Win9x in a separate drive (not in C: and not even "active" and otherwise not bootable by itself). For example, I have a Win98SE-Japanese version in E: drive (the boot win directories are declared inside the a:\msdos.sys) Anyway, using this "Quick Boot diskette", most Win9x drive can be brought up to the GUI world even if the hard disk cannot boot by itself. Once you have the Win32 environment (even in "Safe Mode"), you can use XXCOPY (the 32-bit version) which can restore much of the system files (and a few files are always inaccessible) --- and as Don suggests, you need to perform some copying in the pure DOS (not in a DOS Box) using XXCOPY16 (or for that matter, you may use pretty much any file copy tool) which leads to files which are inevitably in the 8.3 format only. Don's question was why clone did not delete some of the files. The reason is probably because of the way dual-name files behave. That's because the default file-name matching has the "slack" factor. For example, consider this: DEL ???????1.* You will be surprised how many files will match the pattern. That's because nearly all files with a longname has the xxxxxx~1.xxx format where ~1 is the first such file in a series. This should explain Don's observation which is not very intuitive. To enforce the more strict filename matching, use /NP for precise file matching (I guess most of Don' problem should disappear). When you use a 16-bit tool to copy files, it is inevitable that you get a truncated filename (the LFN and SFN both become the same with xxxxxx~1.xxx. No time to panic. XXCOPY.EXE has a way to retrofit the LFN after you copy the files in DOS and later you enter the Win32 environment --- the /NL switch is to do just that!!! XXCOPY d:\backup\ c:\ /s /nl this is not a copy operation. It attaches the right LFN to a SFN-only file. Here, the d:\backup directory supplies the correct pair of SFN and LFN. This operation replaces what Don has been doing by hand. ===================== Reverting to earlier system registry (and other configuration files). from DOS, do this cd c:\windows\sysbckup restreg.bat (here comes the display of DIR RB*.CAB /OD) restreg.bat 003 Here, RESTREG.BAT is run twice. First time, I run it without an argument (and it gives you the syntax for the RESTREG batch file to remind you what to do, and more importantly, it will list the RBxxx.CAB file ---- the compressed system registry and the two key INI file --- WIN.INI and SYSTEM.INI). Here's the contents of the batch file RESTREG.BAT ----------------------------------------------------------------- @echo off if "%1" == "" goto syntax extract /y /e /l c:\windows rb%1.cab goto end :syntax echo. echo RESTREG.BAT syntax echo. echo restreg rbcab_number echo where rbcab_number is three digit (000 - 999) RBxxx.CAB file number echo example: restreg 003 dir c:\windows\sysbckup\rb*.cab /od :end ----------------------------------------------------------------- Here's the background: Win98 keeps snapshots of the four key files (SYSTEM.DAT, USER.DAT, WIN.INI and SYSTEM.INI) into the compressed (.CAB) file. By default, the Windows system keeps the previous five such snapshots. The filename numbering (RB001, RB002, etc.) seems arbitrary and unpredictable. Here's my directory here C:\WINDOWS\sysbckup> dir *.cab Volume in drive C is SINALOA00 Volume Serial Number is 5A65-00A5 Directory of C:\WINDOWS\sysbckup RB003 CAB 2,055,113 08-01-01 10:44a rb003.cab RB001 CAB 2,055,550 08-04-01 2:17a rb001.cab RB004 CAB 2,050,198 08-02-01 10:17a rb004.cab RBBAD CAB 1,834,739 01-26-01 3:28p rbbad.cab RB000 CAB 2,044,810 07-31-01 10:01a rb000.cab RB005 CAB 2,041,599 08-03-01 8:52a rb005.cab RB006 CAB 2,052,792 08-05-01 7:22a rb006.cab RB007 CAB 2,056,084 08-06-01 10:23a rb007.cab RB009 CAB 1,942,977 09-15-01 5:09p rb009.cab RB010 CAB 2,056,891 08-08-01 10:11a rb010.cab RB008 CAB 2,057,613 08-07-01 3:03a rb008.cab 11 file(s) 22,248,366 bytes 0 dir(s) 11,409.59 MB free Here, I have ten such file which are set in c:\windows\scanreg.ini file where I have the following line MaxBackupCopies=10 which declares that I want ten copies rather than five. Anyway, when you extract the components, back to the c:\windows directory, you will basically restore the state of the Windows system. The following operation will do the restore. extract /y /e /l c:\windows rb003.cab Since I run this operation only once is 4-5 months, I don't remember the syntax for EXTRACT. That is why I created the batch file. But, I need to choose which .CAB file I want to use for system restore. The first time the batch file is run, it will tell you the correct syntax for the batch file and the sorted directory listing to assist me for the best choice of the restore. Anyway, restoring the key windows file will usually fix the problem of boot failure to the Windows environment. I would probably fix over 90% of problems. ======================================================= If restoring the key files does not work, then, you want to suspect the MBR and/or boot sector. The MBR is easier to reinitialize: fdisk /mbr will refresh the master boot code section of the MBR. The boot sector is another key component which must be right in order to have your drive boot correctly. sys c: will not only copy the key boot up files (IO.SYS, MSDOS.SYS, DRVSPACE.BIN, and COMMAND.COM), but more importantly in this case, to reinitialize the boot sector. In my case, I would try these steps first before "restoring" the \Windows directory using the DOS environment. Kan Yabumoto ============================================================= At 2001-08-08 21:10, Don wrote: >Hi Folks! > >I use the xxcopy /clone/yy c:\ d:\ for storing a backup copy. > >When Windows won't boot, I use xxcopy16 to copy the backup to the c: >drive. Then it will boot to Windows but have several truncated file >and folder names of course. I handle those by doing a FIND with >nothing but ~ typed in the name field and and deleting all found. >Then I use xxcopy in a Windows box to do the restore again. That all >works fine. > >My question is, since the clone switch is supposed to delete any >files contained in the destination that don't exist in the source, >why do I have to do the FIND operation and delete them manually. I >have tried to omit that step but the files survive the subsequent >copy over. > >Thanks for any insight you can give. > >Don
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.