Windows registry diffs

Hi Ed,

On 11/21/2016 5:52 AM, Ed Prochak wrote:
> On Tuesday, November 15, 2016 at 8:02:04 AM UTC-5, Don Y wrote:
> []
>> I suspect you'd have the same sort of problem I'm currently
>> encountering with the Windows Registry:  how could you
>> "painlessly" track changes made to your "global store",
>> "who" (which process) made them AND easily "undo" them.
>>
>> I've been amused to discover that this *is* possible under
>> Windows; but, much harder under my formal RDBMS implementation!
>> Especially the "undo them" (well, maybe I could build a giant
>> "transaction" around everything but I'm willing to be the
>> RDBMS would die when faced with an open-ended issue like that!)
>
> Since you are working in a RDBMS, I am surprised you have not yet
> tried a transaction history. About 15 years ago, I was contracting
> on an Oracle project. The system build managed a set of transaction
> tables that logged who, what, and when changes were made.

Yes, but a transaction log consumes resources -- FAST!  (fine if you have
lots of spinning media or tertiary storage that you can call upon; not so
fine when your data store is sized for the data that it *stores*!  :> )

To be clear, I've only considered how I would tackle it in my RDBMS
*after* having had to face the problem in Windows' Registry ("Gee, how
would I do this in *my* system?").

The Registry is relatively dense (at least in its "on-disk" form) so
it's conceivable to take a snapshot on Day X and compare against another
snapshot on Day Y.  The individual actions that caused it to transit
from X to Y (through a variety of other states) wouldn't be apparent.
But, you could easily see what was added/removed/changed.

As I use the RDBMS as my sole persistent store (i.e., IN PLACE OF a
filesystem), that snapshot is a lot "bigger" in my case.  And,
carries a lot of metadata that isn't really known (a priori) to be
of use in that eventual comparison.  (OTOH, as the RDBMS relies on it
for its operation, it *may* well be!  So, you can't dismiss it outright)

> We were able to use that tracking storage for the work I was doing
> which was "fixing" data errors. The initial data populated into the
> data base was pretty bad quality from an old ISAM style system. Mainly
> address data, and rural addresses at that. So we iteratively identified
> address corrections, applied them and then found where the change caused
> other issues and could back out the whole change, or even just subsets.

But, its unlikely that each changed datum saw *multiple* changes (?).
I.e., you found a faulty "address" and fixed it.  It's not like you
then decided that the residence had been demolished -- or, placed
on a flat-bed truck and relocated two blocks farther south...

So, a before-and-after comparison would summarize all of your "net"
changes (though without any chronological history or audit trail)

> It does not necessarily have to cost a lot more storage.  A binary
> mapping of what changes in a row of your working table and a separate
> table of those changed columns. Time-stamps and user IDs and such can
> be in the tracking tables also.
>
> I am guessing the RDBMS exists on larger nodes in your system that have
> more resources. But if you are resource limited, then your options are
> limited also and this may not be a possibly option. But I hope it helps.

I have exactly one RDBMS "server" -- the rest of the nodes are 100% volatile.
The whole point was to ensure that "stuff" wasn't being stored in a bunch
of distributed nodes which could complicate reconfiguration and/or replacement
of individual nodes ("Wait!  Don't throw that node out, yet -- I've got to
extract some data from it...")

My Windows solution really only needed to know before-after deltas.  So,
any mechanism I used to achieve that overall goal would be functionally
equivalent (before-after snapshots, incremental logging, etc.).  I just
wanted to know if applications X and Y were in conflict with each other
in any particular way (i.e., if they both tried to manipulate some setting
and "last change wins").

Thinking about how to do this with the RDBMS requires a definite idea
of *what* the goal is to be:  just noticing aggregate deltas can tell me
that the DB is in a state that I hadn't expected -- but, with no idea
as to HOW it got into that state (I can look at the ACLs to see how it
MIGHT have made it into that state but wouldn't have definitive answer).

Knowing that <something> specific has moved to an unexpected/undesired
state, I can add mechanisms to filter any changes and only log the details
of actions that affect that <something>.  But, I then have to hope the
action is repeatable.  If, for example, a user deliberately changed a
setting by some action of *choice*, I have no way of ensuring he will
make that same choice at a future date.

For example, if an executable's image is changed, that *should* only be
the result of an intentional "software update" -- not some rogue process
scribbling in the middle of such an object.  As those sorts of changes
are "significant" (and infrequent), logging details about them is prudent.

OTOH, logging changes to the OGM for the answering machine is probably
a waste of resources...

On 14/11/16 05:34, Don Y wrote:
> Is there a *simple* means (I've already found a complicated one)
> of noting the changes made to the registry by installing X vs. Y?
>
> (Consider the different cases:  install X, then Y vs. Y then X)

This has become an extraordinarily long thread for something
that is answered by a ten-second Google search:

<https://www.google.com.au/search?q=site%3Amsdn.microsoft.com+track+registry+changes>

Clifford Heath.

Op 21-Nov-16 om 23:31 schreef Clifford Heath:
> On 14/11/16 05:34, Don Y wrote:
>> Is there a *simple* means (I've already found a complicated one)
>> of noting the changes made to the registry by installing X vs. Y?
>>
>> (Consider the different cases:  install X, then Y vs. Y then X)
>
> This has become an extraordinarily long thread for something
> that is answered by a ten-second Google search:
>
> <https://www.google.com.au/search?q=site%3Amsdn.microsoft.com+track+registry+changes>

My impression with Don Y is that when he posts a question here he is not 
interested in the answer but just wants to have a conversation; one 
doesn't get that with a Google search.