And I'll PayPal a cash reward to anyone who can help me solve this.

Hmm. Error 10008, yes? And what particular version of Ghost are you using?

From my reading of the source code and the circumstances in which it generates this error, it seems to be that when Ghost is encountering the end of the first span of the image, it's deciding that spanning is disabled rather than going on to the subsequent span files.

When you start Ghost, use the "Options" menu item and check to see whether "Spanning" is ticked (it should be the first item in the first options tab). If it's not ticked, enable it (or equivalently, use "-span" on the command line when first invoking Ghost).

I created the original image using Ghost 2003 after booting to DOS and runing Ghost.exe.

I have purchased Ghost 10, so I could use either.

Ideally, I'd like to do a total restore of the machine. Extracting was my secondary route.

Thank you very much. I'll let you know the outcome, but I'm very optimistic since you knew it was a 10008 error.

Have verified the integrity of the ghost files to make sure they are ok?

The Enable Span was checked.

I did a copy with verify, which was successful, but I don't know if that is the best way to check it. When I use Norton to verify, it gives me the same error as when I try to reimage from it.

Pl clarify. Did the ghost program you used to create verify the imagefile ok or it also gave the same error?

When I ran Ghost and created the original image, I didn't receive any errors at all. I never manually did a integrity check afterwards.

And I meant to say earlier, that from DOS I did a copy with the verify and it copied fine, but when I have Ghost do an intergrity check it gives me that same Uneexpected End Of File error.

As it goes through the first 2 GB, it shows the files it is extracting. Does anyone make a program to directly extract from GHO and GHS files? Apparently Symantec does not.

Obviously there is a problem within the Ghost image file. From a DOS point of view the files are ok.

You will need help from one of the developers with Symantec who knows the innards of the ghost image file. I highly doubt anyone outside of Symantec will be able to figure it out since very few outside have knowledge about the innards of the image file. You will soon hear from someone on this list.

Did you try to open the image file with Ghostexplorer? If so, did the open work ok?

Yes, I did try that and it failed.

I would have to use Advanced Open, and it would see the GHO file and start to load it, and then it asks for the final GHS file in the series. I'd point to it, and say OK, and it would immediately and continually ask for it again and again and again...

Only a developer from Symantec NZ can help you. I am confident they will.

Current NZ time is 2.45AM. So will have to wait for about 6 hours before one their developers will see the msgs.

Anybody? Anyone?

> I created the original image using Ghost 2003 after booting to DOS and runing Ghost.exe.

Thanks; do you happen to recall whether you put the image on a local hard disk, or used a mapped network drive instead?

Unfortunately, the lead developer of the cloning engine was home sick today so I couldn't consult with him on this, because spanning is one of the more gnarly areas of Ghost. I've pulled the Ghost 2003 source code from the archives to get more familiar with how the process worked in the edition you have, but take this with a grain of salt since this is not the code that is my primary responsibility.

Anyway, it turns out that when restoring from a dumpfile, the flag that controls whether Ghost understands spanning comes from the header of the image file rather than from the normal settings. Now, when the .GHO file is written, it assumes that it won't span, and what is supposed to happen when it does end up spanning is that the header is adjusted to indicate that it did end up spanning.

My conjecture, therefore, is that somehow this adjustment to set the "spanned" flag might have gone missing somehow; if this one byte in the image header isn't set right, Ghost won't even try to look for a subsequent span and will instead complain with this error.

In order to be sure, I'd need to have a look at the first section of the first span (i.e., the .GHO file). The way these files are laid out is that the first 512 bytes of every span contains a header that describes what it is. If it's the first span, the next 2048 bytes are another header that describes the contents, and it's this section that contains the "spanned image" marker. So, the first 2560 bytes (0xA00 in hex) are the critical part, and from that I should be able to work out if my theory is right.

I don't think I'll need the raw file data, just a dump; in case you don't have a tool to do this, I've adapted a little VBscript from here http://www.interclasse.com/scripts/dumphexafile.php - you can get from http://nigel.bree.googlepages.com/hex.txt and if you save it as a .vbs file it'll dump the relevant part of an image file out into notepad.

You can e-mail me the dump at nigel dot bree at gmail dot com, and hopefully from that we can work out if my conjecture as to the cause is correct.

Nigel,

That file is on its way.

Thank you so much,
Peter

Thanks to Peter, we've at least found part of what's going on. As conjectured, the "spanning" bit isn't set in the image file header, and we've given Peter a fixup tool for that which has let him recover the data he has.

Unfortunately, it's the case in current Ghost that the "spanning" bit is only written to the header section of the first span once cloning has finished; if this hasn't happened, we are facing the possibility that in fact the image isn't complete for some reason (and this seems to have happened to Peter).

Unfortunately we can't fully determine how this came to pass in the first instance, but the cloning engine lead and I are thinking about what we can do to make this more robust.

After opening the file with Ghostexplorer, try to compile it into a new file name and then see if the new file will let you reimage or extract files.

Yes, he did offer to pay the bounty after getting the fix, so he was as good as his word. Naturally, we couldn't accept it.

Since I get quite a surprising amount of direct e-mail about this, I though it'd be good to provide an overview of what we've learned about these situations along with a direct link to the tool.



Some advice for situations where there are problems opening images:

1) In many of these cases, the root cause is that some data loss has occurred; if Ghost Explorer isn't able to open your image, it's usually because the essential data at the end of the image that Explorer needs to display the content is gone.

In this case, the very first thing to try is recovering the image with Ghost using the -ntexact switch. Ghost processes images front-to-back, whereas Explorer actually processes it from the end (where Ghost stores a summary index of all the spans in the image and all the files as well). If you are lucky then only the index data is seriously damaged and it may restore fine. Even if Ghost fails, if it gets most of the way through there's an excellent chance that the volume can have chkdsk run on it and the content can be recovered.

2) If restoring with Ghost fails with an "End of File" error (number 10008), then the data loss may well have occurred when the image was first taken, and as a result the Ghost header is missing a flag that says it wrote the image over multiple spans. This means that you won't be able to recover the image using Ghost as suggested above, because of the error 10008.

In order to get past that error and restore the image to a disk, you can try using this command-line tool to set the missing "spanned image" flag using the "span" option.

All this is intended to do is get past error 10008 to let you restore the image using Ghost; it probably won't let Explorer run because the most likely cause of the span bit missing is a failure during the image write that also means the end of the image is damaged.

3) The main additional problem aside from actual image data damage that blocks Explorer is when images were taken starting with a image-to-disk and then subsequent spans were continued on CD or DVD. Image spans written to CD or DVD have (for no particularly good reason) a slightly different structure to normal spans; the first span written to a CD contains the regular image header data, but later spans on the same CD do not.

There's a special bit in the .GHO header that tells Ghost and Explorer that spans with missing headers are OK and not to panic. If you start imaging to a hard disk and switch to CD or DVD later on, the structure of the span files is in the CD mode but the restore code doesn't know about it and neither Ghost nor Explorer tend to be happy. There isn't any data loss in this particular case, this is just a design oversight stopping access to the data.

This flag, the "CD bit", can also be set by this tool, using the "cd" option.

4) There are a small number of images where Explorer fails internally while opening them (it doesn't prompt for the last span over and over, as it does if there is actual damage to the image). If you have a version prior to GSS2.0.1, this may be due to a problem handling an unusual layout of some of the internal NTFS data, and the 2.0.1 Explorer may be abe to deal with this case.

In this case, it's a good idea to obtain the GSS2 trialware - it should be that the current trialware is build 1532 and this has the fix to that case. The version of Explorer included in the trialware isn't restricted and should be able to be used fine with images from older versons of Ghost.

[ The exception to this is that Explorer's new NTFS editing won't be useful, because older Ghost versions don't understand the new extensions to the image format. It's best to not "recompile" the images with this version of Explorer if you want to use them with an older version of Ghost. ]

5) If all the above suggestions aren't enough, by all means get in touch. It's a good idea to be able to supply or post a GHOSTERR.TXT file from a failed Ghost restore, because that will tell us a lot more about the overall structure of the image, and in particular the data it contains will give us an idea of what to suggest next.

Because the ghofixup tool needs to modify the file, it won't work when run against something on read-only media.

You should only use it against the first file in an image set, not any subsequent file - although Ghost (especially very old versions) sometimes uses the .GHO extension for later parts of a multipart image on optical media instead of the .GHS extension, the later files have a different internal layout. Only the very first file of an image set (CDR00001.GHO, most probably) contains the information describing the image as a whole, and this is what ghofixup.exe attempts to help with.

So, you need to copy the CDR00001.GHO file (and probably all the rest) to writable media, and run ghofixup against that first file.

The message "Error Number: (27076) Message: Corrupt packet length in compressed image file" indicates real data loss in the underlying file. With that kind of major damage (or possibly marginal media that don't read reliably) if the simple fixup tool doesn't let you extract with Ghost Explorer then it may well not be recoverable.

We could possibly take a look at your images in our labs here in New Zealand to see what (if anything) can be done; you'd need to ship us copies of the DVDs. If you do want to explore that, send Krish Jayaratne a private message on these boards to discuss it.

I haven't used Ghost 2003 and I'm not sure what the error message was when it error out on the restore.  But now you've ran the ghofixup tool, I suggest trying to restore your image again.

Try to restore the image onto a 2nd or data partition/disk.  That way even if the restore fails at some point, hopefully after chkdsk and after you log into Windows you'd be able to access whatever was restored on the 2nd partition.

Cheers,
Bruce

will someone tell me how to get past this message? "Invalid Drive Details. This Probably Isn’t a Ghost Image File" when using GhostExplorer.

Cindy, sorry for not getting to this earlier, but because this forum software isn't very good it's easy to miss out on bumps of old threads.

It's not clear exactly what the problem that Explorer is failing on is; the message probably relates to a thing called the "Drive Structure" which is the table near the start of the first span that describes the disk the image was taken on and the partitions in the image.

Posting the first few bytes of the .GHO files was useful; they do seem to be mostly valid to me from eyeballing them. The ones that begin with "FE EF" are the same as GHS-format spans; on CDs, the first span on the disk has the same header as a GHS-format span. One of the peculiarities of the CD format is that the later spans on a CD or DVD don't have any header at all, and the "CD format bit" is what tells Ghost and Explorer to treat those spans as part of an image despite not having a header.

I can't find that exact message in the current source code of Explorer, since things have been rearranged a bit since 2003. But if you e-mail me (at nigel dot bree at gmail dot com) the dump of the first section of the CDR00001.GHO file, the cloning engine lead and I will be able to decode the Drive Structure for the image and see if we can see anything wrong that is making Explorer have trouble.

Rogerio, your situation with the "End of file" message is covered in section "2)" of this message earlier in the thread; your image is probably missing the "span bit", which you can set using this command-line tool and pointing it at the initial file in your image set.

Setting the "spanned image" bit will only resolve the "end-of-file" error and allow Ghost to continue past the initial .GHO file and proceed onto the span files; your image may have other damage at the very end of the image file and so it may be a good idea to restore with the "-ntexact" flag to Ghost. If you do this, it's more likely that after restoring a chkdsk will be able to recover the filesystem.

Message Edited by SM339 on 12-01-2007 11:05 AM

If there aren't any spans at all, then the original error 10008 - which says that the image is incomplete - is correct, and the image really is incomplete. The tools that adjust the "spanned" and "CD" bits are really only for multi-span cases where the image pretty much is complete (except perhaps for a small amount of damage at the very end).

Error 10040 is basically the same problem as 10008; by using the tool to force the "CD-mode" bit on, you have forced Ghost to assume that the image is spanned, but it isn't happy because there isn't an additional span to go to.

So, the image really is missing a lot of the data, and is incomplete - some of the data will be gone.

The simplest next step is to use Ghost to restore the image to a spare hard drive (ideally with the -ntexact switch, if there are NTFS volumes) and then use chkdsk to try and repair the damage to the restored volumes that results from the image being incomplete. That should let you recover what is recoverable from the image.

Message Edited by hawk333w on 06-17-2008 07:34 AM

Message Edited by hawk333w on 06-17-2008 07:34 AM

I am having extreme difficulities with extracting a ghost image.... it has 15 spanned along with the .gho file.  I have lost all my data from my machine, it give me cant open span 11 error.....  I have performed a check image integrity and it checks fine.... I need help.. can anyone help me?

@scsaperez 

In order for people to help you, you need to provide more info, such as error number, version of SW used etc...etc...etc...

Venga ya tio...

Hi there,

Sorry about continuing this already-long thread, but there seems to be a wealth of knowledgable people here!

I have a backup that my IT department from my last company made for me.  It spans 15 volumes (filename.gho, and filename1.ghs thru filename14.ghs), and the version of Ghost Explorer that they gave me was 8.0.0.984.

The issue I'm having is the following:

- I copy all the files to a single directory on my hard drive

- I use Ghost Explorer to open the filename.gho image.  It asks me if I want to mount the images, since it will take an excessive amount of disk swapping otherwise.

- The image opens just fine, and displays ALL files in the image

- When I go to extract the entire image... the extraction process just simply STOPS 2/3 of the way thru (I have about 30GB of data, and it stops at about 21GB).

- The Ghost Explorer status bar states "Complete".

- I have tried this multiple times, with the same result.

- Yes, I am making sure I am highlighting the top of the volume before extracting to make sure I am trying to extract the entirety of the contents

- Where it "fails" (i.e. stops extracting) is somewhere in the middle within C:\Documents and Settings\USER\My Documents

- It does NOT complete the extraction of "My Documents"

- It does NOT complete the extraction of any user's directories beneath (i.e. after in the alphabet) C:\Documents and Settings\USER

- It does NOT complete the extraction of any sibling directories beneath (i.e. after in the alphabet) C:\Documents and Settings

It is obviously just stopping mid-operation, and I can't figure out why.  I've even tried going to the top of the volume, highlighting all the contents in the window, and extracting that... and it still gets the same result.

Any help would be appreciated!

Thanks,

mattchoo 

Debugging internal problems in versions of the code that are over 4 years old is extremely difficult. First though, it's often useful to check whether the image is damaged or not. If you have 8.x or later then the 32-bit Windows version of Ghost can do an integrity check on the image from within Windows and that is the gold standard as to whether the image is fine, or whether it is corrupt.

From what you describe, I would suspect the image you have is corrupt, and that Explorer is not presenting the data from that point in the image because it has hit some corrupted data and prior to GSS2.5 the Explorer code generally abandons its attempt to expand the image data at the first sign of trouble, and none of the command-line switches really dealt with that (don't bother trying them).

Either way, the best approach with Explorer is to try opening the image with a newer version, since genuine (i.e, not "Norton Ghost" 9 or later, which is a completely unrelated product) Ghost and the associated toolchain is backward compatible to a pretty extreme degree and that's the tool that we want to make the primary one for recovering data from damaged images, and in GSS2.5 Explorer tries much harder to extract data from damaged images.

If you're not a customer of the current version though, pretty much the only way to get at the current version is via either the current trial edition of the full GSS product, since Explorer it's part of GSS and like most things related to Ghost it's licensed code rather than freeware (it'd be nice to have a more readily available edition of the newer Explorer, particularly for customers with truly ancient versions of Ghost, but although I raise this from time to time thus far I haven't got much traction with management on that).

If you try that, it'll at least have a MUCH better chance of working through your image than any earlier version will do, and if it doesn't work opening a corrupted image then I can generally try and do something about it.

Now, if the corruption in the image affects enough of it - for instance, the corruption is in a directory structure - the GSS2.5 version of Explorer can't load that directory. If produces a pop-up telling you that the image is corrupt, that means it's absolutely tried everything it can, and whatever it shows you is all it could recover.

[ I just yesterday made one improvement to the Explorer code since 11.5.0.2113 since a customer reported that it couldn't completely open his corrupt image, but I'm not yet certain quite whether that will be in the next LiveUpdate we make to GSS2.5 or whether I'll be able to make it available as a standalone download somehow. ]

Hello TimdueMo, This is a old thread, started well over a year old, now with five pages of posts. The original topic was in regards to spanned images not able to be restored or opened from Ghost Explorer. Nigel Bree provided workarounds on this issue on page 2. Although you've encountered the same error message, your issue sounds different as your image is not spanned, can be opened in Ghost Explorer and is specific when restoring the image from the two Passport HDs. I'll move your post to create a new thread. If there are relevant issues in this thread please add a link to this thread specifying the points. Thank you, GSS Taniwha

Locking this thread to due size and age. If you encounter this issue and the workarounds provided are not working, please create a new thread with a link to this one.

Thank you,

GSS Taniwha

I have a similar issue.  I ran a GHOST image using 11.5 on a failing drive.  This version does the image in one file rather than smaller blocks (kinda nice, I guess).  However, the drive actually crapped out about 3/4 of the way through the image.  For the life of me, can't get it to spin up one more time.  Is there any way to get the 42GB of GHOST image that I DO have to come up so I can extract at least a portion of whatever is there???

Much appreciated for any help.