Hi Folks,

Has anyone ever succeed in getting the

-LOCKINFO

option to do what the manual says?

In my copy, it does ABSOLUTELY NOTHING!  Ghost merely runs, then exits with a blank screen, and no TXT output files created, nothing, ZIP, Nada...  So how one is supposed to know which Locks will be suitable is a good guess....  (It would be a great feature if it actually worked.)

Ghost 2003 is fast becoming the most irritating piece of commercial false advertising I have ever encountered.

How about the -FNF option?

Or -FDSZ?

Or -BATCH?

Or -DD?  (In my setup, -dd causes G2003 to crash out with a GeneralException - probably because it has a heart attack when it sees its supposed to write to a RAMDRIVE - but where the hell else can it write to, if booted off a CD to restore a Linux system?)

None of these options actually work properly.  The product is more interested in blathering about its licencing requirements than operating within its licence specifications.

Can anyone please recommend a Hard Disk Imaging utility that actually WORKS, for backing up and restoring a 3-partition Red Hat 7.3 Linux system, using a DOS-based, Command-Line driven, Batch-file-controllable program?  Please!  Because Symantec Ghost sure SUX!

(Just like Symantec Norton Anti-Virus - which is harder to remove from your PC than almost any virus.)

Bb

NightOwl,

Thanks for the response, albeit not an answer!  )

I didn't explain it too much, because I've done a lot of work, tried many options, different machines, different BOOT configurations etc etc.  I'd be here all day!

But, basically, I'm running GHOST from DOS (Windows 98SE) which calls itself "Windows 98 [Version 4.10.2222]" and have tried it with and without a RAMDRIVE, with and without HIMEM, etc, with Shift-F5 (Bypass CONFIG.SYS etc) and found various differences but none that solved my problems.

Anyway, since then I have solved ONE problem.

The -LOCKINFO option is incorrectly documented in the manual and everywhere I have looked on the 'net.  That seems surprising, because it would be a great option to use, to prevent an image designed for a certain machine / motherboard from being (accidentally) installed onto a wrong set of hardware, and it's a wonder no one else has had the same problem.  As you probably well know, the modern O/Ss (Win2000, XP - even NT) don't like being installed on one motherboard then moved to another. You are lucky if you can get them to run on the new one.  Anyway, the latest GHOST Manual (pp154-165) says:

"Command-line switches
.......
-lockinfo  Shows the type code and information stored in the BIOS or the Pentium III Processor ID."  (Then it lists the codes and example data... e.g.)

"Type  Based On       Value
  M    Manufacturer    Compaq
  P     Product name   Deskpro EN Series SFF"
etc.

So, the option SHOULD work just like -finger, -help or -ver and simply display the requested data.  But it doesn't.  As I said, Ghost just runs, then exits.  Nothing but a blank screen.  No file generated, containing the data.  ZIP. Nuffing.

Anyway, no doubt it's a dumb bug, badly tested software, because a simple redirect yields the data:

GHOST -LOCKINFO >LOCKINFO.TXT

One down, several to go....

There the main problem, as far as I can tell, is that Symantec has got paranoid about people misusing their say, Single User Licences, and have tried to screw things up to prevent people doing that.  Unfortunately, it has also made legitimate use almost impossible in some circumstances, such as mine.

The second problem, as mentioned above, relates to trying to Ghost & Restore a Linux system.  Up until Ghost 2003 build 793 it never worked (implied that it would in the documentation) on Linux with the GRUB boot manager anyway, but build 793 fixed that, so it seemed worthwhile trying to use it.

That's when I discovered this other great irritation. Because I created my Linux Master under (guess what! Linux), Ghost had not seen the disk before.  When it did, it wanted to stick its dirty little fingerprint on it.  I was using the GUI at the time, to create the Images, and so told it to Continue with no fingerprint (knowing there is an option to ignore this problem) because I didn't know what the fingerprint might do to the Linux partitions and BOOT code (which previous Ghost versions couldn't even recreate anyway).  Fine.  Virgin, unadulterated image created.

Now I want to restore, using a self-booting, self-running CD, that should BOOT and ask (in CONFIG.SYS) what image to restore.  Choose the desired BOOT, press Enter and go away.

Come back sometime later and read the Okay or Failed message, then remove the CD and ReBoot.  I'm planning to do this perhaps once a day (for a specific, legitimate purpose.)

Well, that's when I discovered that the Options DO NOT WORK; while writing the Batch file to drive it.

The Symantec Ghost support page:

http://service1.symantec.com/SUPPORT/ghost.nsf/pfdocs/1998082612540625
(Last Modified:11/03/2004)

listing Ghost command-line switches says:

-FNF   Information   Turns off Fingerprint creation.

The column for Ghost Version has no comments, suggesting it should work for any relevant version.  WRONG!!!

What happens is that the program starts, and complains that the target disk has no fingerprint, even though it isn't supposed to have one, and won't have one when the image has been written anyway.  But it stops execution and sits there asking this dumb question, regardless that it's been told not to.

In other words, it's flatly ignoring the option.  It's interesting, because as far as I can tell, when any invalid option is supplied, it complains that it's an invalid option, but here, it obviously recognises the option as valid, but just ignores it.

What this means is that it's impossible to use Ghost in a batch file without it demanding User Intervention in some circumstances - i.e. when the disk has no fingerprint - like, every time I use it.

So, that's the overview of my current headache, and any solutions you might have would be greatly appreciated.

(The only one I can think of is to go back and let Ghost write it's grubby little fingerprint on the Master Disk, create a new set of Master Images, Load manually then never wipe the target disk before doing an automated Restore, even though DBAN is just fantastic for the job.)

(I haven't got back to the crashout that seems to be due to the RAMDRIVE...  Later...)

Hope you can help.

Cheers,
Bb

Hi NightOwl,

Sorry, forgot to mention that.  Of course I have! It works if the Fingerprint is there, but not otherwise.  "No Fingerprint" seems to override EVERY other option.

Here's my previous test command line:

ghost -FNF -batch -clone,MODE=LOAD,SRC=D:\gho2003\CK28S20D.gho,DST=1 -sure -fx -afile=c:\ghostera.txt -dfile=c:\ghosterd.txt

C:is the RAMDRIVE, D: is the CD.  DOS doesn't see a Linux Drive, even with three partitions.

Cheers...

Umm back...

Quote:


Since I'z gonna cave in on this, I decided to test what you said.

I started Ghost with -FNF.  It complained.  I said "OK" - which it says means it will write the fingerprint.

And guess what?  It does, contrary to your suggestion that it turns it off.  It just ignores the switch completely.

But guess what else?  Next I ran "Ghost -finger", and it repeatedly said: "
1  Not finger-printed
2  Not finger-printed"

(There are now two drives in my system - the Linux Master and a FAT drive to save the Ghost file onto.)

So then I ran Ghost without any options, but I never saw the "I want to write a finger-print on your hardie" message again.  It wrote the finger-prints alright, onto both drives, but now it LIES about it.

In my book, this Ghost is POX!  I'm back to what I said before: Symantec Norton Ghost 2003 SUX!  It's a fraud.

Bb

'Morning NightOwl (well, relative to me, anyway!),

Thanks for your perseverance!

I haven't got to the bottom of this Ghost fingerprint thing yet myself, but I can answer some of your questions....

And you are certainly right about one thing: Symantec's documentation is atrocious.  Even in the latest Ghost 2003 manual, downloaded from symantec.com, options are listed that are seriously wrong.  While I have to concede that the -FNF switch is not even mentioned in this manual (though it is, in lots of other places), and as discussed above, is obviously RECOGNISED by the program as a "valid" option, plenty of other options are wrongly described or have bugs.

Quote:


Sorry, but the short answer is: No.  I'd have to say you obviously like Ghost and are - well - perhaps willing to gloss over or minimize its faults...?  Do you work for Symantec...?

Anyway, what I perhaps bluntly stated last night appears to be entirely the case.  Ghost is as blunt and brutal as I am!  When I include the -FNF switch, it ignores it completely.  When it runs, the VERY first thing it does is look for a fingerprint on ***ALL*** the hard drives it can find.  Then, REGARDLESS of **ANY** switch telling it to ignore the (lack of) fingerprint, or clear the fingerprint (-FDSZ), or run in Batch mode, it breaks out of "normal" execution, displays the GUI and demands user intervention.

Here's a good test to try, with a brand new, non-finger-printed second disk, that has absolutely nothing on it (Not even partitioned).  Use a small image that you previously made (e.g an empty or small partition - just for the sake of speed), saved on your first drive.

Now run ghost (from the first drive, or from floppy) as follows:

GHOST -FNF -QUIET -CHKIMG,filename

I know -FNF does absolutely nothing, but 'quiet' really should do what it says...  Which, on p162 (top) of the abovementioned manual, is:

"-quiet  The quiet mode switch disables status updates and user intervention."

Whatever that's supposed to mean... Does it mean the GUI remains OFF, and it operates like a normal DOS command-line program, or does it mean the GUI appears but user intervention prompts are just not asked?  Or what?

Yeah, good question!

Here's what it really does.

1. It finds No Fingerprint on the second drive, even though I have not at this point asked Ghost to do anything whatsoever, in relation to the second drive. Frankly, the 2nd Drive is None of Ghost's Damn Business!  It certainly should not be trying to write to it, particularly when running in DOS.  It doesn't own the drive, and for that matter, nor might I.
2. The GUI appears.
3. The irritating "There's no fingerprint" message box appears, asking its 3-way question: [OK] [Cancel] [Continue without marking drives]. 
4. I say "Continue..."
5. DOH!!!!!!  How about that?  Next, message box "Question: (1814)" appears, and says: "Proceed with image file integrity check?"  SO much for "quiet"...
6. I choose [Yes].
7. The GUI status line reports: "Partition is compressed"
   The GUI displays its normal "Progress Indicator" [0% 25% 50% 75% 100%] but the progress bar remains invisible - no progress is reported.  [This would seem to be what "quiet" really does... ;-((( I mean, how pathetic.]
8. There is hard drive activity...
9. After a while, message box "Verify complete (1498)  ! Image file passed integrity check [Continue]" appears.
10. I click "Continue"...  The GUI closes, a blank screen with Command Prompt, top left, appears...

In other words, Ghost just doesn't do what the manual claims.  Obviously, the Boxed Product is now intended for the SOHO / Home User market, and Symantec have tried to break it so it can't be used to clone multiple drives, and well, they have succeeded.

It's broken.

Clearly, what they should do is decide the Boxed Product is GUI only, and not waste everyone's time with this Command-line switch fiasco.

Quote:


In the light of the above, almost everything the program does is an 'undocumented feature'!!!

I used to think Micro$oft was bad, and lied in their documentation, but Hey, Symantec is worse.

Quote:


Continuing my testing today, I can confirm that the -BATCH option does seem to have SOME effect.  In the example above, adding the -BATCH option (to a DOS prompt command...) causes Ghost to skip all the user prompts in relation to the integrity check aspect, but it still starts the GUI and complains about the lacking fingerprint.  And the GUI remains up until the program exits, but at least it doesn't ask for any MORE user intervention.

But, basically, neither -QUIET nor -BATCH work properly. NORMALLY, in relation to DOS programs, "Quiet" means don't display any output to screen.  (In other words, don't tell the user what you are doing.) Ghost certainly doesn't conform to that foolish notion.

And in my book, -BATCH should make the program do exactly that - take all its commands from the batch environment - and if that results in an ambiguous or impossible set of instructions, it should abort with an appropriately documented errorlevel...

But instead, when it isn't given its undeserved candy, it throws all its toys out of the sandpit, throws a big tantie, and displays the GUI with an unnecessary User Intervention question.

As far as I'm concerned, in most cases, Ghost has no right to insist on fingerprinting a drive.  If the user wants to, well and good.  Otherwise, Butt Out!


Anyway, I still haven't got this Fingerprint BS sorted out yet, but what I can tell you is that it appears to have two different styles of fingerprint (Like a true criminal, it wears gloves sometimes!) and it writes its dirty little fingerprint to Track 0, Sector 62, on the 63 SPT drives I'm using.  Then, later, it claims "I never touched it!"  LIES!!!!

When it writes it in response to the prompt above, it only writes a few bytes - maybe a couple of dozen, but it's still fingering your drive.

However, at other times, it writes a whole lot more, including the name and address that Ghost is registered to.  I haven't figured that out yet.  Maybe when it Restores a drive it writes the full fingerprint...  I haven't been doing that lately, I'm so snarled up in trying to get it to obey simple BATCH file commands.

But when it writes the small fingerprint, it LIES about it when you run "GHOST -FINGER" and says the drives are not fingerprinted.  That is DISGUSTING. Why LIE? 

The truth is that if it's not complaining, then all your drives have been FINGERED, probably at sector 62. 

Now what I want to know is what happens if Sector 62 contains legitimate system code...? E.g. Drive Overlay code, or a boot manager...


Finally, your idea that it somehow modifies itself to save the fingerprint data is incorrect.  It asks the same old question over and over until you let it have its wicked way with your hardie.

And I still think it SUX!

Yours....
Monica
P.S.  If anyone knows of a half-decent, Linux-capable Hard Disk Imaging program that can run from DOS, please let us all know.  [And Yes, I've still got "Bill's Dress".]

NightOwl,

You are a veritable mine of useful information!  I don't know how you keep finding all this stuff on the Symantec site, but it's very good.  I'm looking into the "switch options" options now.

Obviously, Ghost is / was really a very good program, that has been mangled by a few poorly implemented attempts to cripple it for the SOHO / Home User market.  I wonder how I can get a two-node Enterprise License...

Anyway, I'll be back when I have more to report.

Right now, I have just finished re-generating my (4) images with my drives "FINGERED"...  This time I also included -locktype (since I figured out how to get the lockinfo), so we'll see how that goes.  I suppose it's an ill wind that blows no good.

While I'm here, let me see if I can clarify the confusion from my previous post.  As I said, I don't believe the -FNF option has any effect at all.  I think Ghost ignored the option entirely. I believe that what the letters stand for are "Force No Finger-print", which, aided by descriptions I have read elsewhere, I take to mean (and it is borne out by the wording of the User Intervention box message), NOT "Skip the Fingerprint check" BUT "Don't write fingerprint(s)".  It certainly ties in with observed behaviour - i.e. it wrote the F-P, even though I had the (disabled) -FNF option set.

So I probably confused the issue by including the -FNF option in my example at all, but my view is it makes no difference to what happens, which is that, ONCE you have permitted Ghost to write finger-prints, Ghost never throws up that message box again.  It simply writes that bit of dirt to your drive(s), then finds it(them) again every time, so skips the message.

I don't know if I understand your confusion correctly, or if I'm explaining this better, but nothing (much) happened (changed) between replies 6 & 8, except that I actually allowed Ghost to "finger(print)" my drives.  And if you don't, it just keeps on complaining, every time you run it.  Whether the -FNF option is included or not.  Basically, forget -FNF.  Ignore it, like Ghost does.  It does nothing.

My big issue is that even though I allowed Ghost to write its nasty little fingerprint onto my drives, which made it happy and caused it to stop throwing its toys out everytime - because a fingerprint was actually there - when I asked Ghost to tell me if there IS a fingerprint there, it LIES about it and says "Not finger-printed."

Here's the evidence:

Norton Ghost 2003 Copyright (C) 1998-2003 Symantec Corp. All rights reserved.


Disk  Last Norton Ghost Action    Date     Time   Clone-ID
------------------------------------------------------------
  1   Not finger-printed
  2   Not finger-printed
  1   Not finger-printed
  2   Not finger-printed
  1   Not finger-printed
  2   Not finger-printed
  1   Not finger-printed

*** End of diagnostics ***

But I tell you, both drives are fingerprinted, and Ghost now never whines that they are not.

As for "disk ID" versus "fingerprint", I would say there is almost certainly no difference, unless of course they mean short F-P versus Full F-P.  But what I don't understand is what Symantec is playing at, with this whole F-P thing.  There is no need for it, except to try to tie a Ghost Licence to a drive.  I'd say it's just a bit of a lie, saying it "NEEDS" to mark a drive for Ghosting... It's a con.  I really can't see what value there is in writing to the Source Drive.  Ahhh, maybe that's it?  Maybe the short f-p goes on the Source, and the Long one on the Target.  I'll let you know...

But I still can't see any point to writing on the Source.  Sure, include a finger-print on all BATCH-Made Clones.  That makes sense, and I wouldn't have any problem with that unless I was making a forensic copy.  And finger-printing all (non-forensic) clones would achieve the licence policing (evidential) purpose.

So I honestly can't see what they're playing at, and it's probably just SDI...  Unless, I suppose, it's part of some Image Tracking package that I haven't yet played with?  But then, why wouldn't it admit that?  You can usually tell a lie by the refusal to admit the intent of some strange request.

Later...

Yup!!!

Just to clarify for anyone else who may be interested:

The -FNF option does not appear to have any effect at all.

Ghost (2003 build 793, 775,...) just ignores the option, and always displays the GUI and demands User Intervention if it finds drives that it hasn't Fingered, ID'd, or whatever they want to call it (and it doesn't find an overriding option, such as -help or -ver).  I think it's a crap thing to do, but that's what it does.

And if you choose "Continue without marking drives", it doesn't fingerprint them, but everytime you run Ghost, it will ask you the same question again.

THEN, if you do say [OK], it will write a "fingerprint" or diskID - a nasty little bunch of bytes to Track 0, Sector 62 on each drive it finds.  Once it has done that, it will not ask you the "Can I Finger your drives" question again, until the "fingerprint", "signature" or "diskID" is deleted.

BUT, if you then immediately ask to about fingerprints, it will say "Not finger-printed".  Maybe this is being "clever" and distinguishing between a "diskID" and a "fingerprint", but clearly, it considers one the same as the other as far as asking the "Can I finger (or ID) your drives" question, and as far as I'm concerned, whatever it is called, it is a violation - unwanted rubbish unjustifiably written to a Source hard drive.

THEN, if you clone a drive (say by writing the previously created image) to another drive, the clone drive will have a "Long Fingerprint" (as opposed to a "non-existent" one, discussed above), and then Ghost will actually admit to there being a fingerprint, like so:

Quote:


All I can say is that it's a great pity that Symantec has made such a hash of what is obviously a great piece of software, and packaged it as Boxed Product for sale to Non-Enterprise users, but hasn't updated the documentation to reflect the mangling it has done.

And, FWIW, the 'SystemWorks 2005 Premier' Boxed Product only has Ghost 2003 build 793 (the same), for DOS / Win 9x / WinMe, and Ghost 9.0 for 2000 / XP.

Night, night...

Hi again NightOwl,

You have obviously done a more thorough analysis of what Ghost is doing to Sector 62 than I have.  I don't know how you identify the separate areas on S62 as "files", but never mind.

The only points I would have to clarify and/or contradict you on are as follow:

1: Quote:
 

Yes...  and NO! Ghost allows you not to ID your drives - TRUE.

But it also does NOT allow you to run Ghost from a BATch file without User Intervention if ANY drives in the system in question are not previously "ID'-ed".  I think that sux, but C'est la Vie!  That actually defeats part of its functionality, but I suppose their argument is "How many people would repeatedly legitimately write an image to a clean drive without breaching their single user licence?"  I suppose not many, but I would, if I could.  I only have two PCs (and now, two Ghost licences), but my testing does create that situation.


2: Quote:


I can't see / find any evidence to suggest that the -FNF switch works in any way or does ANYTHING at all in the Boxed Product version of Ghost 2003 build 793.  You say that the -FNF switch might disable the fingerprint being written (even though it still nags, which, in that circumstance would be the epitome of True Nags), but I proved earlier that even though -FNF was there, choosing [OK] to the nag screen caused the ID to be written.  I think that point confused you before, but if you read it again, I think that's what I did say, more or less!


BTW, I tested the -LOCKTYPE feature and pretended to try to install my image to another machine.  LOCK worked, and wouldn't do it.  COOL!

While I was at it, I tested the -LOCKINFO option again, on that same machine.  Even though the machine is MUCH faster than the Linux box, I got a different (interesting) result.  If you turn the lights off, it's even more apparent.  When I run GHOST -LOCKINFO, the screen momentarily flashes blue.  If you look closely, you can even see the normal Ghost GUI appear for an instant, then disappear, then after a moment more, the Command prompt returns.  (I don't see the GUI flash at all on the Linux box.)

So, it's a bug!  Possibly, the LOCKINFO data is being displayed in the GUI interface, but is then whacked by a CLS, and they forgot to put in any User Intervention request this time.  Pity they can't swap it from the diskID code!


Finally:
Quote:


Understatement of the week!   

Which brings me back to my suggestion that most of what they say in relation to this whole "ID" / 'finger-print' justification is actually untrue / deliberately misleading / plain BS...!

Cheers,
Bb