My bootable cd

Use at your own risk.
The batch file will ghostback your latest ghostfile.gho to first
unhidden primary partition.

Assumption
   ghostfile.gho is located in main directory on one drive
   ghostfile.gho is name as ghostfile1.gho, ghostfile2.gho etc.



Can download the file here...

Link to download removed by NightOwl


[edit]Edit by Nightowl--6/23/2012 at approx. 11:00 am

Your download appears to contain a working copy of *ghost.exe*--that's a protected, licensed program by Symantec, and distributing it would be a violation of their EULA!  That's the one main rule we have here on our forum--no distribution of licensed software that is not freeware or in the public domain for free use and distribution.

I have temporarily removed your link.

You can offer a download without that proprietary program that others can then copy their properly licensed version of the program to the boot disc, disk, or usb flashdrive. [/edit]



config.sys  -------------


device=himem.sys /testmem:off /numhandles=128 /Q


device=AHCI.SYS /D:sata
device=UIDE.SYS /D:gen
device=emm386.exe NOEMS I=B000-B7FF
device=ansi.sys
shell=\command.com /e:2048 /f /p

fileshigh=40
buffershigh=15
dos=high,umb
stackshigh=0,0
fcbshigh=4,0
LASTDRIVE=Z
BREAK=ON

autoexec.bat -----------------------


@echo off
prompt $p$g
SET TZ=GHO-08:00

echo Loading driver...
LH MSCDEX.EXE /D:sata /D:gen /L:x
LH doskey.com /insert
LH mouse

set cddrv=
findcd -e -r
if errorlevel 23 set cddrv=x
if errorlevel 24 set cddrv=y
echo %cddrv%: CD drive with media
path a:;%cddrv%:

cls
ntfs4dos findG.bat


findG.bat ----------------------

rem autoghost findG cd version

@echo off

rem booting from cd


rem hd c       hd1,1 -- assign c
rem hd d       hd1,2 -- assign d
rem hd e       hd1,3 -- assign e



rem Check drives for existence of .gho file and return drive letter

set drive=
if exist D:\*.gho set drive=D:
if exist E:\*.gho set drive=E:
if exist F:\*.gho set drive=F:
if exist G:\*.gho set drive=G:
if exist H:\*.gho set drive=H:
if exist I:\*.gho set drive=I:
if exist J:\*.gho set drive=J:
if exist K:\*.gho set drive=K:
if exist L:\*.gho set drive=L:
if exist M:\*.gho set drive=M:
if exist N:\*.gho set drive=N:
if exist O:\*.gho set drive=O:
if exist P:\*.gho set drive=P:
if exist Q:\*.gho set drive=Q:
if exist R:\*.gho set drive=R:
if exist S:\*.gho set drive=S:
if exist T:\*.gho set drive=T:
if exist U:\*.gho set drive=U:
if exist V:\*.gho set drive=V:
if exist W:\*.gho set drive=W:
rem if exist X:\*.gho set drive=X:
rem if exist Y:\*.gho set drive=Y:
if exist Z:\*.gho set drive=Z:

%drive%
FOR %%l IN (*.gho) do set ghofile=%%l

set drive2=
if exist D:\*.gho set drive2=1:2
if exist E:\*.gho set drive2=1:3
if exist F:\*.gho set drive2=1:4
if exist G:\*.gho set drive2=1:5
if exist H:\*.gho set drive2=1:6
if exist I:\*.gho set drive2=1:7
if exist J:\*.gho set drive2=1:8
if exist K:\*.gho set drive2=1:9
if exist L:\*.gho set drive2=1:10
if exist M:\*.gho set drive2=1:11
if exist N:\*.gho set drive2=1:12
if exist O:\*.gho set drive2=1:13
if exist P:\*.gho set drive2=1:14
if exist Q:\*.gho set drive2=1:15
if exist R:\*.gho set drive2=1:16
if exist S:\*.gho set drive2=1:17
if exist T:\*.gho set drive2=1:18
if exist U:\*.gho set drive2=1:19
if exist V:\*.gho set drive2=1:20
if exist W:\*.gho set drive2=1:21
rem if exist X:\*.gho set drive2=1:22
rem if exist Y:\*.gho set drive2=1:23
if exist Z:\*.gho set drive2=1:24


echo.
[0;32;40m
echo  * Ghost file
[1;33;40m%ghofile%
[0;32;40m at drive 
[1;33;40m%drive%
[0;32;40m
echo  * check if disk:volume 
[1;33;40m%drive2%
[0;32;40m  match the table above else
[1;33;40m
input " * type the correct disk:volume =  " drive2 /E /L4
echo.
[0m

if exist d:\windows GOTO part2

echo ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:1 -FX
pause
ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:1 -FX
goto done

:part2

echo ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:2 -FX
pause
ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:2 -FX
:done
cls
ej %CDDRV%:
ECHO --------------------------------------------------------------------------------
ECHO Please remove the CD now
PAUSE
restart

AHCI.SYS   ---  dos sata cd driver

ej.com  ---  eject the CD-ROM tray
EJ.COM    v1.04    2003-07-01    Charles Dye    raster@highfiber.com

findcd.com  --- find where the cd is located if you have more than one cd drive
FindCD v1.02, (c) 2000-2001, Bart Lagerweij
27 nov 2001, http://www.nu2.nu/contact/bart

Ghost.Exe  ---  dos v11

input.com  --- enable to input from keyboard

mscdex.exe   --- Microsoft MS-DOS CD-ROM Extensions

ntfs4dos.exe  ---  Avira NTFS4DOS enables a large number of DOS programs to access NTFS-formatted drives.
http://avira-ntfs4dos-personal.avira-gmbh.qarchive.org/

pause.sys  --- Pause `Config.sys'  for debugging
  PAUSE - Pause `Config.sys' processing
  1997-2006 BTTR Software

RESTART.COM  --- restart the computer from dos

UIDE.SYS  ---  dos ide generic cd driver 
get latest UIDE here
http://johnson.tmfc.net/dos/driver.html

@ an illusions

Impressive!  Some very advanced functions.


Quote:

Can download the file here... https://www.box.com/files#/files/0/f/0/1/f_2478300863

Looks like this requires signing up with the *Box* website.

It will take some time to digest how the various components of the *config.sys* and *autoexec.bat* work--I have not learned how variables in DOS are used--and you use several in the various commands above.

You have some interesting programs that enable nice functions.  Not sure where this fits in:


Quote:

pause.sys  --- Pause `Config.sys'  for debugging   PAUSE - Pause `Config.sys' processing   1997-2006 BTTR Software

I see that *pause* is called by your boot files in serveral places--but I thought *pause* was a standard DOS command available without having to add a separate program.  Are you using *pause.sys* in your above *autoexec.bat?  Wouldn't this conflict with the DOS *pause* function?

Sounds suspicious???? Having to create a "Box" account and then finding the file has been deleted!

@ Nightowl  @Brian

Sorry, the link to download should be

Link to download removed by NightOwl


[edit]Edit by Nightowl--6/23/2012 at approx. 11:00 am

Your download appears to contain a working copy of *ghost.exe*--that's a protected, licensed program by Symantec, and distributing it would be a violation of their EULA!  That's the one main rule we have here on our forum--no distribution of licensed software that is not freeware or in the public domain for free use and distribution.

I have temporarily removed your link.

You can offer a download without that proprietary program that others can then copy their properly licensed version of the program to the boot disc, disk, or usb flashdrive. [/edit]




@ Nightowl

Pause.sys is use in config.sys  and does not conflict with autoexec.bat    pause function.

for example if you would like to test each line in config.sys


device=himem.sys /testmem:off
device=pause.sys

device=AHCI.SYS /D:sata
device=pause.sys

device=UIDE.SYS /D:gen
device=pause.sys

etc ....


device=pause.sys <--- should be removed after debugging

more info here

http://www.angelfire.com/electronic/tristar/debug/debug/InsertPausesInConfigSys.html

@ an illusions

Thanks for the new download link. Hey, that is nice. Way out of my league but I'm going to keep playing until I understand it better. I've already done a few semi-auto restores.

One observation. The partition containing my .gho file is correctly calculated as disk3 volume1 but the yellow text says it is 1:4. I can change this to 3:1 and the restore takes place. Impressive.

@ Brain

NTFS4dos always calculate the correct disk and volume number but my dos batch assume there is only 1 harddrive.   Therefore, I added the Input function so you can correct the disk and volume to the right one.   :D

@ an illusions

I moved the .gho to the first HD and now it works as you described. I understand.

Edit... Does this work from a USB flash drive or does it have to be on a CD?

Just saw your USB link.

@ an illusions

LBA-62 on HD0 is "marked" during the restore process. Can this be avoided?

Brian wrote on Jun 23^rd, 2012 at 12:51am:

LBA-62 on HD0 is "marked"

Sorry, I never encountered such error msg.   

Maybe you should create a new ghost.   Format that partition again and ghost back.

Forget my comment. That happens anyway. It's not related to your CD.

Haven't looked at the second thread yet, but some comments on this thread . . .


Observation #1:

The first group of "if exist" statements can be simplified with a foreach loop:

for %%d in (d e f g h i j k l m n o p q r s t u v w z) do if exist %%d:\*.gho set drive=%%d:

Observation #2:

As designed, the script searches for .gho files only in the root directory of each drive.  It does not search subdirectories.



Observation #3:

As designed, the script expects there to be only one .gho file per drive.  If you have two or more .gho files, it takes the last one in the directory list.  Unfortunately, there's no way to consistently predict which .gho file that will be.  As files are written/rewritten, the order they appear in the directory list gets shuffled around.  It is not chronological, nor is it alphabetical.  Thus, if you use this script you should make sure you only have one .gho per root directory.



Observation #4:

As designed, the script expects there to be only one .gho file altogether.  If you have two or more drives with a .gho file in its root directory, the script takes the last drive it searches.



Observation #5:

As designed, the script assumes all drive letters refer to partitions on a single HDD.  It doesn't accomodate scenarios where the .gho file is on a secondary HDD, external HDD, CD/DVD, or network share.



Observation #6:

As designed, the script assumes that if it finds a D:\Windows directory, that D: refers to the second partition on the first HDD.  That can't be guaranteed.  It depends on the how many HDDs, their specific complement of primary vs extended partitions, and which of those might be FAT, FAT32, or NTFS.  Remember, DOS gets to assign drive letters first before ntfs4dos.exe gets its hands on what's left.



Observation #7:

Syntax error in findG.bat, line: "if exist d:\windows GOTO part2".  That DOS instruction does not check for a directory named windows, it checks for a file named windows.  To check for a directory, use the syntax: "if exist d:\windows\nul GOTO part 2".



Observation #8:

NightOwl's right--there seems to be some confusion with the "pause" command here.

First, Reply #1 refers to it as pause.sys, which means it's a device driver, not an executable you can call from a program or batch file.  With rare exception, device drivers need to be loaded via config.sys (e.g., via "device=pause.sys"), but there's no such line in config.sys.  Third, it's purpose is described as "Pause config.sys for debugging", but there are no pause commands used in config.sys.  Perhaps the author had it in config.sys during development and removed it after he was satisfied with the operation of his config.sys file?

As for whether it conflicts with DOS's pause command, there's no conflict, per se, but it may not be behaving as the author may have intended.

DOS follows very rigid rules.  All commands are categorized as internal commands or external commands.  Internal commands are those built into the command interpreter.  External commands are those that take the form of a standalone executable file.  External commands that come with DOS are typically stored in the C:\DOS directory by convention, but they don't need to be.  They could be anywhere.

When executing any command, DOS first looks to see if it's an internal command.  Next it looks for an external command (an executable file) in the current working directory.  If it's not in either of those places, it consults the PATH environment variable and begins searching those directories sequentially, following the priority in the PATH variable.  DOS stops at the first match it finds.  If you have multiple possibilities (e.g., two copies of "myprog.exe" in different directories) you need to understand the DOS search sequence to predict which copy it will find and run.

In this case, "pause" is an internal DOS command, so that takes first priority.

Aside:  For anyone curious about this notion of internal commands, try this: open a copy of command.com in Windows Notepad.  (Of course, you can't use notepad to edit a binary file, but all we're doing is looking for text strings.)  Scroll all the way to the bottom of the file.  Near the bottom you'll plainly see the jump list of internal commands.  Accompanying each command's text string is a four-byte jump vector (invisibly shown as blocks in a text editor) specifying the location elsewhere in the binary file where the actual code for that command begins.



And finally:

I see the author has included an "input" command to accomodate a bit of manual correction, though it doesn't address all of the potential trouble areas in the above observations.

Even at that, the input command assumes you know the correct disk:volume you want, so seems to presume some technical savvy.  Yet, how reliably can a user predict which order Ghost will enumerate HDDs?  How reliably can a user predict how Ghost enumerates volumes?  It's not strictly by physical position, it also depends on whether they are primary or logical.  If you keep your system very simple, you stand a good chance of getting it right.  But for a script wanting to have universal applicability, I'm not so sure.

At the very least, there should be some declaration of when this script won't work, so the user can avoid potential failure scenarios--some of which could have disastrous consequences.

@  Dan Goodell 

Thank you for writing all the observations.   Yes, the batch file has its limitations.   I have uploaded the file so if any DOS expert
knows how to improve the batch file please revised it.


Dan Goodell wrote on Jun 23^rd, 2012 at 1:55am:

Observation #1: The first group of "if exist" statements can be simplified with a foreach loop: for %%d in (d e f g h i j k l m n o p q r s t u v w z) do if exist %%d:\*.gho set drive=%%d:

Yes, and thank you.

For the second part Tech Support Guy forum -- Squashman suggested me this coding but it does not work on windows 98se DOS

set drive2=
FOR %%G IN ("E=2:2" "F=2:3" "G=2:4" "H=2:5" "I=2:6" "J=2:7" "K=2:8" "L=2:9" "M=2:10" "N=2:11" "O=2:12" "P=2:13" "Q=2:14" "R=2:15" "S=2:16" "T=2:17" "U=2:18" "V=2:19" "W=2:20"  "Z=2:24") DO (
     FOR /F "TOKENS=1,2 DELIMS==" %%H IN ('echo %%~G') DO (
           if exist %%H:\*.gho set drive2=%%I
     )
)



Dan Goodell wrote on Jun 23^rd, 2012 at 1:55am:

Observation #2: As designed, the script searches for .gho files only in the root directory of each drive.  It does not search subdirectories. Observation #3: As designed, the script expects there to be only one .gho file per drive.If you have two or more .gho files, it takes the last one in the directory list.Unfortunately, there's no way to consistently predict which .gho file that will be.As files are written/rewritten, the order they appear in the directory list gets shuffled around.It is not chronological, nor is it alphabetical.Thus, if you use this script you should make sure you only have one .gho per root directory.

Actually it does work if you have more than one ghost file in the root directory.   It will use the latest ghostfile.gho as long as you name it as
filename1.gho, filename2.gho, filename3.gho etc.

I don't know how to code it to search sub directory.



Dan Goodell wrote on Jun 23^rd, 2012 at 1:55am:

Observation #5: As designed, the script assumes all drive letters refer to partitions on a single HDD.It doesn't accomodate scenarios where the .gho file is on a secondary HDD, external HDD, CD/DVD, or network share.

As long as all SSD, HDD (SATA or IDE), external HDD are format in NTFS,  NTFS4dos can mapped it.  And if the coding assume the wrong drive and volume number,  the input command allowed the user to override and input the right one as per NTFS4dos mapping.   Yes, it does not work on network share.  The config.sys does not have network share drivers.



Dan Goodell wrote on Jun 23^rd, 2012 at 1:55am:

Observation #6: As designed, the script assumes that if it finds a D:\Windows directory, that D: refers to the second partition on the first HDD.That can't be guaranteed.It depends on the how many HDDs, their specific complement of primary vs extended partitions, and which of those might be FAT, FAT32, or NTFS.Remember, DOS gets to assign drive letters first before ntfs4dos.exe gets its hands on what's left. Observation #7: Syntax error in findG.bat, line: "if exist d:\windows GOTO part2".That DOS instruction does not check for a directory named windows, it checks for a file named windows.To check for a directory, use the syntax: "if exist d:\windows\nul GOTO part 2".

I am using windows 98se dos and when i run the batch it does not have DOS syntax error msg.
This coding is for situation of DELL, ACER laptop where
there is a hidden primary partition in disk1, volume1
c drive windows os  is in unhidden primary partition disk1, volume2

if exist d:\windows GOTO part2
echo ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:1 -FX
pause
ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:1 -FX
goto done

:part2
echo ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:2 -FX
pause
ghost.exe -CLONE,MODE=PLOAD,SRC=%drive2%\%ghofile%:1,DST=1:2 -FX

:done

@ an illusions


an illusions wrote on Jun 21^st, 2012 at 6:06pm:

findcd.com--- find where the cd is located if you have more than one cd drive FindCD v1.02, (c) 2000-2001, Bart Lagerweij 27 nov 2001, http://www.nu2.nu/contact/bart

This might be a better direct link to the above for downloading:

findcd.zip

For a description: 

FindCD

an illusions wrote on Jun 21^st, 2012 at 5:48pm:

Can download the file here... Link to download removed by NightOwl [edit]Edit by Nightowl--6/23/2012 at approx. 11:00 am Your download appears to contain a working copy of *ghost.exe*--that's a protected, licensed program by Symantec, and distributing it would be a violation of their EULA!  That's the one main rule we have here on our forum--no distribution of licensed software that is not freeware or in the public domain for free use and distribution. I have temporarily removed your link. You can offer a download without that proprietary program that others can then copy their properly licensed version of the program to the boot disc, disk, or usb flashdrive. [/edit]

Sorry, my mistake.

Here is the correct one without ghost.exe

https://www.box.com/s/91ad0e32dd43adc83184

Dan,


Dan Goodell wrote on Jun 23^rd, 2012 at 1:55am:

Syntax error in findG.bat, line: "if exist d:\windows GOTO part2".That DOS instruction does not check for a directory named windows, it checks for a file named windows.To check for a directory, use the syntax: "if exist d:\windows\nul GOTO part 2".

I created a 50 MB FAT partition at the start of the HD which put the WinXP partition into 1:2. I renamed the WinXP "Windows" directory to "Window" (using a TeraByte app).

When I used the CD it wanted to restore the Ghost image to 1:1.
I renamed "Window" to "Windows" and the CD wanted to restore the Ghost image to 1:2.

I ran a whole battery of experiments in a virtual machine, and the results are frightening.

First, I confirmed that the "if exist d:\windows" test does indeed work as you described, but only for NTFS partitions.  However, that's even more troublesome than I thought.  That means the ntfs4dos guys screwed up and broke the standard DOS syntax.  Even worse, the "d:\windows\nul" test does NOT work in ntfs4dos--which means you have two different and incompatible syntaxes, depending on whether you're testing a NTFS partition or a FAT/FAT32 partition.  Not cool.




an illusions wrote on Jun 23^rd, 2012 at 12:22pm:

Actually it does work if you have more than one ghost file in the root directory. It will use the latest ghostfile.gho as long as you name it as filename1.gho, filename2.gho, filename3.gho etc.

You're presuming the foreach loop tests filenames alphabetically.  That's not how DOS works.  It tests filenames in the order they appear in the directory, which need not be alphabetical nor chronological.

If you want to explore this for yourself, boot to real DOS and try this:

• create a "test" directory.
  
• CHDIR into the test directory.
  
• create a plain text file and call it 1.TXT.
  
• copy 1.TXT 2.TXT, so you now have two text files.
  
• create the following batch file and call it "test.bat":
  
  @echo off
  for %%d in (*.txt) do set test=%%d
  echo test env var is "%test%"
  echo.

Now, enter the "dir" command and take note of the order of the two text files.  Enter "test" and test.bat will report the last of the two .txt files "dir" encountered.  Now open either .txt file for editing (e.g., "edit 1.txt"), and save it again.  Retry "dir" and note whether the files are shown in the same order.  Try edit/saving 1.txt and 2.txt several times, in any order.  After each save, check "dir" again.

You should discover that the directory order changes, seemingly at random.  In every case, however, test.bat will always show whichever file is last in the "dir" list.

Tech note: the directory order is not actually random.  With each save, DOS actually writes a new file before it deletes the original file.  DOS never sorts the directory order, and new files are simply added to the first open slot that DOS finds in the directory.  That may be at the bottom of the list, but not always--once a file is resaved and the original deleted, you now have an invisible hole in the directory list.  The next file to be resaved will go into that hole, not at the bottom of the list.

(Caveat: we've already established that ntfs4dos breaks DOS's rigid rules.  Therefore, it wouldn't exactly be a surprise if ntfs4dos breaks the directory ordering rule, as well.  If it does, that makes script behavior even less predictable.  Double uncool.)

Regardless, the real problem here is there's no provision for correction when the script selects the wrong .gho file.



In my VM tests, I was able to create several scenarios in which the script failed miserably.

Here's one example:

Scenario: HD1:1 = SRP (NTFS), HD1:2 = Windows (NTFS), HD1:3 = Data (NTFS)

Result: the script restored the OS image to HD1:1

Here's another:

Scenario: HD1:1 = Windows (NTFS), HD1:2 = Data (NTFS), HD1:3 = Data (FAT32)

Result: the script restored the OS image to HD1:2

How happy would you be if you lost your data partition like this?

And these are just a couple examples with one HDD and one OS.  Things get even less predictable if you have multiple HDDs or a multiboot configuration.

It's worth observing that the author has used an "input" command to allow for correction of the image source location, but there is no provision for correction of the restore destination.

I'm not trying to be a stickler here, but whenever anything like this is presented to the public, the risks and dangers should be qualified.  To remain mute and not call this out would be irresponsible.  Other readers could infer the script has been vetted and is safe to use.  That's true whether it's a script, a program, a registry edit, a sector edit, repartitioning, or whatever.  If the task can cause damage, the user needs to be aware of the risk.  In this case, "automatic" and "universal" are contradictory design goals that IMHO should never be put together.

Perhaps the world's most famous and widely distributed Ghost automation script is the "Dell/Symantec PC Restore", of which I have written extensively.  Dell is a big company.  If they get it wrong, it affects millions of people.  Dell has wisely limited the scope of their script to require the Ghost source and destination to be in a specific location.  If they're not there, the script doesn't go out and try to find them, it just bails out and says, "Sorry, I can't do this."

Personally, I believe Dell chose the right strategy in limiting the scope of their script.  Automating the process isn't what's bad, it's trying to be too universal.  If the task is predictable and repeatable, then by all means, automate it.  If you're always backing up A to B and always restoring B to A, there's little danger in automation.  But if you expand it to try and do too much, you'd better be darn sure you've made it as bulletproof as you can.  Unwittingly leading users into trouble just ain't kosher.

Understand, it's not the author's programming skill I'm taking issue with here, it's the design objective of being both automatic and universal.  We've focused on some particulars in the way the author has done some things, but that's not really my point--it's the basic premise that's flawed.  I don't believe it's possible to do this safely--at least, not without reprogramming it entirely in some higher level language where you have control over all interfaces and how every piece of information is handled.

A Rube-Goldberg assortment of DOS commands, "sort-of-DOS" commands, and third-party utilities--all using inconsistent terms and standards, is a project I wouldn't trust could ever be made safe in a very broad scope.  (Just look at this thing, for goodness sake ... in some places it's looking for drive letters; in other places it's going by disk:partition references.  That's not the author's fault, it's the Rube-Goldberg nature of the pieces the author had to work with.)

I personally would never use a script like this on a real system.  Scripting is fine for very specific cases, but if the source and/or destination can't be guaranteed to be in specific places, I consider it far more sensible to run Ghost manually, where I can be sure what's going on.  Ghost just isn't that difficult to use that it needs this.

Dan,

I ran your scenarios. I'm convinced.

@Dan

Thank you for pointing all those issues and senarios.   Back to the drawing board ...   :-[

@ Dan Goodell


Dan Goodell wrote on Jun 24^th, 2012 at 2:02am:

I personally would never use a script like this on a real system.Scripting is fine for very specific cases, but if the source and/or destination can't be guaranteed to be in specific places, I consider it far more sensible to run Ghost manually

Your responses have been most enlightening--I appreciate your time/efforts here!


Dan Goodell wrote on Jun 24^th, 2012 at 2:02am:

whenever anything like this is presented to the public, the risks and dangers should be qualified

I have assisted folks here on the forum in the past with *automating* Ghost backups and restores--but, I have usually stated before and/or after offering such assistance that I'm not a fan of *automation*--it has a high risk of going awry if you have misused the correct syntax of any one command--be it DOS or a Ghost cloning command!

One is always safer if doing an automated Ghost *backup*--not likely to destroy data!  It's the *restore* commands that hold a greater risk!

I have suggested that if one is going to attempt *automation*, that you not try it on your *only* or main system.  If you have only one system, then create cloned spare HDD(s), place those in the system and do testing on those before attempting it on your *production* system.

And, it's always a good idea to run each command that you want to *automate* manually first to verify that it does what you want it to do without errors or hiccups.

And, always have a separate backup that is stored off the system's HDD(s) just in case you have to restore the system after an *automatic* scenario has gone awry.


Dan Goodell wrote on Jun 24^th, 2012 at 2:02am:

I ran a whole battery of experiments in a virtual machine

I'm going to have to learn how to use a *virtual machine*! 

Don't virtual machines have the ability to access the *real machine*?  How do you protect the *real machine* from the experiments you're doing on the virtual machine?

@ an illusions


an illusions wrote on Jun 24^th, 2012 at 8:35am:

Thank you for pointing all those issues and senarios. Back to the drawing board ...

Don't be discouraged!

I want to thank you for presenting your DOS programming.  I wish more folks would do the same thing!  I've have often asked folks to do exactly what you did--present the actual *config.sys* and *autoexec.bat*--along with a list of files that they are using on their boot media--so it can be analyzed and evaluated.  That's how we learn on this forum!  But, most folks will not do so--darn anyway :( -- concerned about being embarrassed--or have something to hide  :-/ --I guess !

You have shown me some new DOS programs, and commands that may be very helpful in the future--I'll be testing them.

an illusions wrote on Jun 24^th, 2012 at 8:35am:

Back to the drawing board ...

My advice would be to scale back your design goals.  IMHO, you're trying to make the script too universal.

Selection of the restore destination is the most dangerous part to try and automate.  If the script gets it wrong, the results can be catastrophic--an "epic fail", as the youngsters like to say.

You might consider hard-coding the restore destination in the script.  Presumably, you're not planning on using the same physical CD on a thousand different computers, you're probably going to use it on no more than a couple.  Therefore, your restore destination can be a fixed value.  Your source images might be scattered amongst various places, but your restore destination doesn't change for a given computer. 

If your computers don't all have their Windows partitions in the same place, you might need to build a couple CDs and label them, "Restore script for Billy's laptop", or "...Sarah's Lenovo and Office PC", for instance.

By hard-coding the destination and only using a given CD on specific computers, at least the script won't get the wrong destination, and the worst that can happen then is if the script restores the wrong image.  And if that happens, it's not fatal because you can always repeat with the right image.

You can take it one small step further and combine CDs with a custom menu to pick from a predetermined list of destinations, ala:

Select which PC you are Restoring:
• Billy's laptop
  
• Sarah's Lenovo
  
• Office PC

The point is to not let the script determine the destination location by itself.  That's the most critical decision in the whole Ghost process, so unless you can be absolutely certain the script will never get it wrong, don't let it do it.

@Dan

Once again thank you Dan for taking the time to write all those comments and ideas. 

@NightOwl

Thanks for the encouragement and kind words.   

@Brian

Thanks for kind words and being BOLD enough to test the CD / USB method on your computer.

Cheers  :)

NightOwl wrote on Jun 24^th, 2012 at 10:35am:

I'm going to have to learn how to use a *virtual machine*!

You really need to, NightOwl--what's holding you back?  You're the kind of guy who would find all sorts of useful things to do with it.  Email me (addr on my webpage) if you want help or advice on what to choose.

It probably would have taken me at least ten times longer to run through all the aforementioned tests if I had done it on real iron.




Quote:

Don't virtual machines have the ability to access the *real machine*?How do you protect the *real machine* from the experiments you're doing on the virtual machine?

No, VMs are totally isolated.  That's the beauty.  A VM is effectively a separate machine on your home network.  So yeah, there's access across the LAN to the same extent as a real machine on the LAN might have, but that's all.  In fact, the standard way of moving files back and forth between the host and a VM is via network sharing--just like you would do with real machines.  The host and VM don't see each others' drives unless they're shared across the network.  The VM even gets its own IP addr from your router.

If you were to perform these hard drive tests on real iron, you no doubt know that other machines on the same LAN are in no danger if something malfunctions.  It's exactly the same with a VM--what goes on (or wrong) in a VM poses no danger to other machines on your LAN, including the host machine the VM is running on.  (The VM doesn't see the host machine as anything special, as far as it knows it's just another machine on the LAN.)

Now, if something might pose a risk of coming across the LAN (such as a worm infecting one of your machines), you're vulnerable to the same risk from a VM.  But other than that, the machines are isolated.

@ Dan Goodell


Quote:

You really need to, NightOwl--what's holding you back?

Inertia mostly! 

Until recently, I had older systems (circa 2002 or 2003) which I assumed would not work well--but, I could be wrong about that--so need to explore recommended minimum system requirements.

And, just making time--any new software that has any degree of complicated-ness has its own learning curve requirements--but, with this comment:


Quote:

It probably would have taken me at least ten times longer to run through all the aforementioned tests if I had done it on real iron.

Maybe I've been *wasting* time  :) !


Quote:

Email me (addr on my webpage) if you want help or advice on what to choose.

Actually, if you're willing, rather than proceeding via email, would you be willing to do this publicly on the forum here?  I could start a new thread on *how to setup and use a virtual machine*.  I've been known to endure publicly embarrassing myself by demonstrating my lack of knowledge of just about anything computer hardware and software!


Quote:

The host and VM don't see each others' drives unless they're shared across the network.

Okay--so the VM is *isolated*--got that.  But, how about CD and floppy drives--these are on the VM's host machine--does the VM somehow get to share those physical devices?

And how does the VM work as a separate machine--is it in RAM, is it taking up HDD space for storage of caches, etc.  If I understand--the VM can be saved as a file--so, as you add programs in the VM--you can save your work and bring it back later on a new session?  How big a file does that become--same as a standard Windows OS partition (i.e. how much HDD space is needed--and where on the HDD?)?


(I need to do my *homework*--read up on VM's to determine system requirements, etc.  Your recommendation on which VM to use--free or paid version--easy vs hard to use version, etc.?)

NightOwl wrote on Jun 26^th, 2012 at 10:29am:

Okay--so the VM is *isolated*--got that. But, how about CD and floppy drives--these are on the VM's host machine--does the VM somehow get to share those physical devices?

Careful, your preconceptions are showing!   ;D

True, the host machine can usually be switched to give either the host or the VM access to the physical floppy or CD/DVD drive, but that's not really necessary.

Think: it's a virtual machine . . . so why not a virtual floppy drive and virtual CD/DVD drive??

In the aforementioned VM tests, I built the test script into an iso, then just drag-and-dropped the iso into the VM's virtual CD drive.  When I wanted to change the script I rebuilt the iso and dropped that into the virtual drive.  No physical CD was ever burned!




Quote:

how does the VM work as a separate machine--is it in RAM, is it taking up HDD space for storage

For starters, see if this helps:

Introduction to Microsoft Virtual PC

Quote:

rather than proceeding via email, would you be willing to do this publicly on the forum here? I could start a new thread on *how to setup and use a virtual machine*.

Perhaps.  One-on-one is easier because there's one skill level I'm dealing with, whereas a public tutorial takes more effort because it has to be exhaustive enough to cover a breadth of possible skill levels of potential readers.  I guess I'm not sure if there would be enough interest to justify the extra effort.

Also, in watching discussions in other online venues I've seen many a simple VM question obfuscated by others jumping in and arguing over why their favorite VM app is better than yours, or by VM snobs proclaiming it's stupid to even try VMs unless you have 8 cores and 16GB of ram (which of course they'll remind you, they have and you don't).  A thread whose purpose was to go from A to B ends up going off the rails before ever getting to B, and the original poster goes away feeling VMs are just too complicated.

So I'm not crazy about your proposed thread title because it invites that kind of "this-vs-that" debate instead of sticking to a "how to".



(edit: couldn't think of the word I wanted before . . . "preconceptions" . . . fixed now.)

@ Dan Goodell


Quote:

Think: it's a virtual machine . . . so why not a virtual floppy drive and virtual CD/DVD drive?? In the aforementioned VM tests, I built the test script into an iso, then just drag-and-dropped the iso into the VM's virtual CD drive.  When I wanted to change the script I rebuilt the iso and dropped that into the virtual drive.  No physical CD was ever burned!

Hmmm....makes sense--so in addition to learning the new software to create the VM, also need to brush up on creating optical iso's and floppy images to drag and drop......  ;) !


Quote:

Also, in watching discussions in other online venues I've seen many a simple VM question obfuscated by others jumping in and arguing over why their favorite VM app is better than yours, or by VM snobs proclaiming it's stupid to even try VMs unless you have 8 cores and 16GB of ram (which of course they'll remind you, they have and you don't).  A thread whose purpose was to go from A to B ends up going off the rails before ever getting to B, and the original poster goes away feeling VMs are just too complicated.

Made me laugh  ;D .

I understand your point.  Some time ago in a thread, I *gored* someone's sacred cow by suggesting that a software program was not acting in accordance with their preconceived notions.  Even though I presented the evidence for everyone to review and test--it was quite testable--this person could not get past their tightly controlled world of *black and white*--and kept hammering me for suggesting *shades of grey*!  I don't think the thread went completely awry, but there was a tendency to wander.  I don't think the other poster ever *really* came around--or *forgave* me for presenting the evidence that I did!

@ Dan Goodell


Dan Goodell wrote on Jun 26^th, 2012 at 7:51pm:

For starters, see if this helps: Introduction to Microsoft Virtual PC

OMG--a *Dan Goodell* tutorial on Virtual Machines!!!!!

I still think your Understanding MultiBooting is one of the *gold standards* if you truly want to *understand multibooting*!

I have some *fun* summer reading ahead of me!