Radified Community Forums - Auto ghost back the latest ghost and eject the cd

an illusions

Dude

Offline

I Love Radified!

Posts: 13

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #15 - Jun 23^rd, 2012 at 3:04pm

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

Can download the file here...

Link to download removed by NightOwl

Edited:

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.

Sorry, my mistake.

Here is the correct one without ghost.exe

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

IP Logged

Brian

Demigod

Offline

Posts: 6345
NSW, Australia

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #16 - Jun 23^rd, 2012 at 6:10pm

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.

IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #17 - Jun 24^th, 2012 at 2:02am

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":

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:

Result:

Here's another:

Scenario:

Result:

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.

IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #18 - Jun 24^th, 2012 at 2:02am

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.

IP Logged

Brian

Demigod

Offline

Posts: 6345
NSW, Australia

Back to top

	Re: Auto ghost back the latest ghost and eject the cd Reply #19 - Jun 24^th, 2012 at 3:04am Dan, I ran your scenarios. I'm convinced.
	IP Logged

an illusions

Dude

Offline

I Love Radified!

Posts: 13

Back to top

	Re: Auto ghost back the latest ghost and eject the cd Reply #20 - Jun 24^th, 2012 at 8:35am @Dan Thank you for pointing all those issues and senarios. Back to the drawing board ...
	IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #21 - Jun 24^th, 2012 at 10:35am

@

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?

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #22 - Jun 24^th, 2012 at 10:48am

@

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 Sad

-- concerned about being embarrassed--or have something to hide Undecided

--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.

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #23 - Jun 24^th, 2012 at 4:19pm

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:

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.

IP Logged

an illusions

Dude

Offline

I Love Radified!

Posts: 13

Back to top

	Re: Auto ghost back the latest ghost and eject the cd Reply #24 - Jun 24^th, 2012 at 5:16pm @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
	IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #25 - Jun 25^th, 2012 at 4:50am

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.

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #26 - Jun 26^th, 2012 at 10:29am

@

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.?)

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

Dan Goodell

Special Guest

Offline

Posts: 552
N California

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #27 - Jun 26^th, 2012 at 7:51pm

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! Grin

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.)

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #28 - Jun 27^th, 2012 at 10:15am

@

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...... Wink

!

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 Grin

.

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!

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

NightOwl

Radministrator

Offline

"I tought I saw a puddy
tat..."

Posts: 5826
Olympia, WA--Puget Sound--USA

Back to top

Re: Auto ghost back the latest ghost and eject the cd
Reply #29 - Jun 27^th, 2012 at 10:37am

@

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!

____________________________________________________________________________________________

No question is stupid ... but, possibly the answers are Wink

!

IP Logged

	Welcome, Guest. Please Login