Suggestions for a way to prove/refute this?

Hello all,

Ian's ChunkBrowser smoothly recovered some things that were lurking in my
apparently broken 5.1 image - thanks again Ian!!  Now I'm left with question
of what happned and why.

Whatever the cause, it either has to affect the OS or other files (so far
virus scans are negative), or it has to be transferred via packages, because
images built from packages didn't work.  If it lives in files, it also has
to be conditional, because an image from Wednesday AM seems to work.

One theory that is starting to make sense is that I might have damaged my
5.0 image by exiting while compressing changes.  I thought that was
impossible, but managed to do it in validating the restored 5.0 image.

By "validating the restored image", I mean loading it onto a machine that
has "had its shots", take it into and OR, hook it up and watch numbers fly
out of it.  The machine in question is a 500 MHz Celeron.  The restored
image worked.  Queue sighOfRelief.wav.

Still, _something_ bad happened, and it could happen again, so I kept
digging.  The change log was ~17MB, just slightly bigger (natch) than the
one from the working 5.02 backup.  Still, that's a prettty big log.  I
hadn't yet considered a truncation, but I was concerned that the size was a
sign of trouble.  So I compressed changes, waited long enough (I thought),
saved the image and exited.  On reloading to repeat the test, I got a
walkback re a missing temp file.  Just for laughs, I put the restored image
back on the drive; it loaded w/o incident and obtained data.

At this point, I started to suspect that I might have built the broken
images from packages saved after a truncated compress.  So I saved packages
from the restored image (on the pen tablet to avoid corrupting one of my
development boxes), and transferred them to a new directory on another box.
I was hoping to see a huge difference in size between packages, perhaps
suggesting a place to look in one of the broken images.  There are
differences, but nothing suggestive.

Going back to my 2.x GHz P4, I placed a MessageBox>>notify: at the end of
#compressChanges, and find that I can indeed invoke menu commands while the
compress is cooking.  I theorize that this is what happened early on
Wednesday morning, after which I copied the hobbled image onto my machine at
work, saved packages from it, and re-re-built a 5.1 image that I used for
acceptance testing that failed when I finally reached the intraoperative
part of it.

So, am I sounding more like Sherlock Holmes or Geraldo Rivera? :)  My
problem with this is that I find it hard to believe that the image, abused
as described, would even load, let alone save packages, without complaining.
If it did happen, how would I prove it?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,
[]
> So, am I sounding more like Sherlock Holmes or Geraldo Rivera? :)  My
> problem with this is that I find it hard to believe that the image,
> abused as described, would even load, let alone save packages,
> without complaining. If it did happen, how would I prove it?

I also find it a bit difficult to believe that you would be able to save
packages from an inconsistent image/change log combination in a way that
wouldn't cause massive problems when you try to reload the packages.  If
it was possible to save packages while the sourceDescriptors held in the
image contained offsets into the wrong source file (and I'm not
convinced that this is possible to get in that state) then every method
source saved in the packages would be corrupt.

I think you've really got to find the _actual_ differences in the
packages and work from there.  If you have a working 5.0 image and also
copies of the packages that won't run when reinstalled then I would have
thought it quite possible to resave the packages from the 5.0 image and
do an exact comparison across the contents of each set of packages.

If you don't want to automate this process you could probably do it one
package at a time using the ChunkBrowser.  Install the CB into your 5.0
image and then open each package in turn in the CB.  Anything in the
package that doesn't exactly agree with the current image will be
flagged with a red cross.

BTW. I'm aquainted with SH but who is Geraldo Rivera?

--
Ian

Ian,

> I also find it a bit difficult to believe that you would be able to save
> packages from an inconsistent image/change log combination in a way that
> wouldn't cause massive problems when you try to reload the packages.  If
> it was possible to save packages while the sourceDescriptors held in the
> image contained offsets into the wrong source file (and I'm not
> convinced that this is possible to get in that state) then every method
> source saved in the packages would be corrupt.

Understood, but several things point in that direction.  I didn't take it
all seriously until I saw that walkback on the pen tablet - a lot of stuff
worked in that image.


> I think you've really got to find the _actual_ differences in the
> packages and work from there.  If you have a working 5.0 image and also
> copies of the packages that won't run when reinstalled then I would have
> thought it quite possible to resave the packages from the 5.0 image and
> do an exact comparison across the contents of each set of packages.

One problem is that I might no longer have the (potentially) offending
packages in their original state.  In this case, I have 5.1 packages on CD,
but it is clearly after I discovered the problem, because there are a few
#outputDebugString: sends that would not have been present otherwise.  They
are not the work of gremlins, I remember adding them, and (per timestamps
and the code they contain) I obviously resaved some packages from 5.1 after
making those changes.



> If you don't want to automate this process you could probably do it one
> package at a time using the ChunkBrowser.

With 100+ packages to scan, and even more .pac files (some obsolete, some
loaded only when there is a need), automation is the only way it was going
to happen :)   A little scripting of ChunkBrowserModel did the trick.  I
used a health (I hope!) 5.0 image and parsed the 5.1 and 5.03 packages, with
some of them re-saved after the 5.1 image was built.

I created one CB model per package, and stored the non-matching chunks it
selected in a stream on a new array, and then inspected the results.  I did
not shove all of that into another CB model, but doing that would be helpful
because the CB would then be useable to browse the results.

That aside, the 5.1 image is very close to my restored image.  That's not
surprising, because I parsed its change log to recover work that would have
otherwise been lost.  Based on the #rawText from the flagged chunks, there
was nothing that didn't make sense given my tracing efforts after
discovering the problem.  The 5.03 image shows more differences (the CB
would have been helpful here), but it again seemed to make sense given what
it should and should not contain.

Based only on the code, things are not looking good for my theory.  However,
we have not addressed scripts, nor what happens when the packages are
loaded.  I'm hesitant to run 5.1 or even one of the damaged images until I'm
in a position to check the data collection soon after doing so.  The smart
play for me now seems to be to stick with 5.0, at least for the next few
days. Maybe Blair's investigation into the MS SDK will find an explanation.
Another idea is to load one of the broken images and save packages from it;
again, I don't want to do that until I can verify the data collection.


> BTW. I'm aquainted with SH but who is Geraldo Rivera?

Interesting; I thought his recent flop in Iraq would have gotten him more
attention than that.  He went overboard with details and the US military
arranged the end of his war coverage.  More generally, one might describe
him as a cross between Jerry Lewis (in character) and Ted Koppel.

Thanks!!

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]