NightOwl wrote on Sep 1st, 2013 at 9:39am:@
ElipsisWow! That's a huge Ghost file set!
I don't want to brag... but... yeah I hear that alot.
NightOwl wrote on Sep 1st, 2013 at 9:39am:Could you share what *header utility* you are using?
How did you decide which header was corrupt--just the change in the pattern seen in the other headers vs the one you have highlighted in red above?
It was based on some research I did just googling other people with similar problems.
I think it was in
this discussion that I had found
this hex dump .vbs.
NightOwl wrote on Sep 1st, 2013 at 9:39am:What version of Ghost are you using? A 4G file size suggests that it is probably one of the Corporate Ghost versions, and probably above the 8.xx.
Nigel Bree, (a former Symantec employee on the development team for Ghost) in the past, on the Symantec Ghost Solution Suite Forum, has attempted to help a number of individuals with corrupt image files. But, he is no longer with the company, and support for Corp Ghost appears to in the decline--there is evidence that Symantec is abandoning all forms of Ghost, both retail and corporate.
But, you could try posting your question to that forum to see if anyone can help there:
Symantec Ghost Solution Suite (GSS) support forum I'll have to go back and check, but I believe it was made with Ghost 11 run off of a separate bootable Windows P.E. recovery disk. I've noticed that Nigel Bree seems to be the
only person who is remotely interested in Symantec Ghost having
any semblance of the ability to recover from ghost image files from errors and corruption. It was based off some of his responses to other people with similar problems that directed me to look at the headers in the first place. I'm looking for the result that I found where someone posted something
very similar to what is happening to me... I think it was
this.
NightOwl wrote on Sep 1st, 2013 at 9:39am:You could try booting to DOS (or running *ghost32.exe* if you use that program), and running an integrity check (using any switches that might help with a corrupt image set) just to make sure Ghost will not access that image set.
If by any chance, Ghost will access the image set successfully in DOS, you could try to restore the image to a test HDD, and see if you can access the files in that fashion.
Beyond that, unfortunately,we here have not seen any way to repair a corrupt image set.
The integrity check fails when it gets to the part of the span that is supposed to go to the corrupt span. It prompts me for the next file and accepts nothing I give it as any use. I don't think I'll be able to restore the image if the integrity check is telling me that the ghost is no good.
NightOwl wrote on Sep 1st, 2013 at 9:39am:That's disturbing on several levels. The Ghost image files should have been a *read only* file set as far as Ghost Explorer and Windows are concerned. Why would a shutdown and reboot have any effect on an image set and the individual file headers? I could see a shutdown affecting the integrity of a file being restored that's in mid-restored state--but the image file header.....hmmm?!
Were you using Ghost Explorer to modify the image set in some way when the event happened?
Don't I know it! My friend and I were talking yesterday about how the eff an operation that should by all rights be
read-only managed to corrupt the headers on the file it was reading. My best guess would be sloppy coding. I certainly had no intention to
modify the data that was part of the ghost, in fact I don't think Ghost Explorer can even do that, can it? I honestly have no idea. What's more upsetting is that the one bad file stops Ghost Explorer, as well as the regular ghost program, from doing anything useful with the spanned ghost. At
worst you think it would be able to go from span 26 to span 28 and just lose
some of the data...
...
...
...
Wiiiiiiiiiith all that said... I made a desperation maneuver since my original post and solved my problem. The solution that worked was to
manually hex-edit 027.ghs. After making a copy of it... I opened it up in a hex editor and changed it to this:
FE EF 09 00 45 21 1F 52 9C 9C FA FF 1A 00 00 00
Some of these values were just pattern matching off of 026.ghs and 028.ghs - while others I just completely made up. (I believe they are just the timestamp?)
Anyway I stuffed my mauled version of 027.ghs back into the sequence of files... and believe it or not... the thing worked! Ghost took my file and managed to load everything up in ghost explorer. It seemed to then extract everything I wanted out of there normally. If there is any corruption in the payload of 027.ghs, I'll probably never find it - as that section of the span correspond, mostly, to one large video file... which is a file format that handles errors rather gracefully.
Thanks for getting back to me.