I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/12/2024 14:10, Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

If you are imaging the C: drive while the system is running then not
everything is copied because some files are protected by the operating
system while they are used.

You can create a rescue media which can be used to boot-up the machine
to clone/image the system disk.

You asked how long this has been going on. The short answer is as long
as "MOST" imaging software were created. I never backup the system disk
while the machine is running. Rescue Media is what I use 100% of the time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer <ed@somewhere.in.the.uk> wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

I've not seen that message. Image backup, or logical (file) backup?

Some causes could be interrupted backup process, not enough space for
the backup on the destination drive, power outage even if momentary,
write error on the destination drive, interference by anti-virus
software, running high or critical priority processes that hog the CPU
so Reflect cannot function. Did you check the backup log?

Did you get a Windows update, but have not rebooted yet to ensure the
fileset was in sync that got changed?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

I've not seen that message. Image backup, or logical (file) backup?

Some causes could be interrupted backup process, not enough space for
the backup on the destination drive, power outage even if momentary,
write error on the destination drive, interference by anti-virus
software, running high or critical priority processes that hog the CPU
so Reflect cannot function. Did you check the backup log?

Did you get a Windows update, but have not rebooted yet to ensure the
fileset was in sync that got changed?

I've been doing this same C backup for years. Suddenly the message appears. I've often restored from the image; always successfully.
Today's backup finished ok. The log just says image completed successfully.

Maybe you're right about some critical priority process running. Just a
very infrequent coincidence. I'll see what happens next time.

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12/1/2024 9:10 AM, Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that I've not seen before; a warning that parts of the operating system wouldn't be saved.
How long has this been going on?

Ed

Macrium usually makes a log file of some sort.

The error message could be slightly more detailed there,
about the issue.

Something is wrong with VSS on your setup, but I don't
have a nice testbench for you to run or anything.

The following command, is merely to get you some breadcrumbs
for a Google search. The log is where you really need to look.

vssadmin list shadows # as administrator

In services.msc , check the Volume Shadow Copy service.
Startup type is listed as "Manual" and mine is stopped right now.
This suggests we won't know how "healthy" VSS is, until Macrium
tries to start it. And if there is a fault, it will not be
breathing oxygen for very long. Maybe the vssadmin invocation
will start the service running ?

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12/1/2024 9:18 AM, LiverpoolFC Fan wrote:

On 01/12/2024 14:10, Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

If you are imaging the C: drive while the system is running then not everything is copied because some files are protected by the operating
system while they are used.

You can create a rescue media which can be used to boot-up the machine
to clone/image the system disk.

You asked how long this has been going on. The short answer is as long
as "MOST" imaging software were created. I never backup the system disk
while the machine is running. Rescue Media is what I use 100% of the time.

Incorrect.

Most all of the backup softwares use VSS during a backup.
This is a mechanism for doing "hot" backups of the C: partition
in particular.

The way this works, is softwares with issues (like the OS), they
have to have a "provider" to quiesce certain files. When VSS is
triggered and a shadow copy made (a "frozen" snapshot of the OS partition), there is a ten second interval, where the providers are told it is
time to quiesce. And that's when the shadow is made.

Some files have not been getting backed up. Perhaps the Windows.db or Windows.edb of the SearchIndexer did not get backed up. I don't
think the Pagefile.sys gets backed up. Even though the traffic level
on that file is a *lot* different than in past OSes, it is unlikely
to be a good candidate for the design.

Thus, you will find things missing from a backup. But these are
also not "critical" items. If the pagefile.sys was replaced with
a like-sized file of zeros, you'd never notice at boot time.

And the Windows.edb can be regenerated. As a derived file, it's
not a critical file.

As the system gets more features involving virtualization,
it's hard to comment on the "things you can't see". Maybe
something like that is causing the OPs problem.

But generally speaking, the OS and the applications
are familiar with VSS and the shadow copy system and this
is why we're not freaking out about making backups
while the computer is running.

*******

Now, *if* a users computer has a problem, such as the VSS subsystem
is down, then on Macrium at least, it switches to PSS and that
is its own invention. That likely would be missing some additional files.

I would interpret the OPs message as an indication that
something is wrong with VSS, as a first approximation.

Shadows can be persistent or non-persistent. Macrium may use
persistent shadows for "incremental forever" or "incremental".
There have definitely been cases of some competing backup
products, using up all 64 shadow slots and running out! And
that would represent a failure of sorts. A design failure
by the backup software maker.

vssadmin list shadows

On WinXP, the difference was supposed to be, it did not support
persistent shadows, and you could have a shadow long enough to
make a full backup without a problem. I wasn't always convinced
that it did not have persistent shadows, as sometimes the shadow
list had an entry or two that should not have been there.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 01/12/2024 15:10, Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

Really strange.
I use Macrium Reflect for many years, and have never seen anything like
this. Never had a problem.

Fokke

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer <ed@somewhere.in.the.uk> wrote:

VanguardLH wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

I've not seen that message. Image backup, or logical (file) backup?

Some causes could be interrupted backup process, not enough space for
the backup on the destination drive, power outage even if momentary,
write error on the destination drive, interference by anti-virus
software, running high or critical priority processes that hog the CPU
so Reflect cannot function. Did you check the backup log?

Did you get a Windows update, but have not rebooted yet to ensure the
fileset was in sync that got changed?

I've been doing this same C backup for years. Suddenly the message appears. I've often restored from the image; always successfully.
Today's backup finished ok. The log just says image completed successfully.

Maybe you're right about some critical priority process running. Just a
very infrequent coincidence. I'll see what happens next time.

Ed

I figured to look at the log for the backup job that issued the warning
that system files couldn't be backed up.

I'd probably also run "chkdsk /r" on the drive to give some assurance
all clusters can be read.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

PaulNoSpam suspects a VSS error.
The Reflect folder contains file "vssfixx64.exe".
Run that and see if it helps.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul in Houston TX <Paul@Houston.Texas> wrote:

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

PaulNoSpam suspects a VSS error.

The Reflect folder contains file "vssfixx64.exe".
Run that and see if it helps.

The OP hasn't look at the Reflect log for the failed backup job, so the
error code noted in the article below may not be what he got:

https://knowledgebase.macrium.com/display/KNOWX/VSS+Error%3A+0x8004230F

I have Reflect, and it already has the vssfixx64.exe in its folder. The properties for mine says it is version 1.0.2.1. The downloaded x64 file
from the above article is the same version.

Besides the possible causes already mentioned, I didn't about the OP
using another VSS product, like ShadowProtect.

https://knowledgebase.macrium.com/display/KNOWX/VSS+fails+due+to+modification+by+3rd+party+software

"vssadmin list writers" will show what others there are. Nothing popped
out as obvious for Reflect's VSS writer. The names aren't all obvious. "vssadmin list providers" only shows me the one from Microsoft. At HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Providers in
the registry, there is only 1 entry (showing the MS provider). Perhaps
a VSS provider can register themself at the time they are called.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

VanguardLH <V@nguard.LH> wrote:

Paul in Houston TX <Paul@Houston.Texas> wrote:

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

PaulNoSpam suspects a VSS error.

The Reflect folder contains file "vssfixx64.exe".
Run that and see if it helps.

The OP hasn't look at the Reflect log for the failed backup job, so the
error code noted in the article below may not be what he got:

https://knowledgebase.macrium.com/display/KNOWX/VSS+Error%3A+0x8004230F

I have Reflect, and it already has the vssfixx64.exe in its folder. The properties for mine says it is version 1.0.2.1. The downloaded x64 file
from the above article is the same version.

Besides the possible causes already mentioned, I didn't about the OP
using another VSS product, like ShadowProtect.

https://knowledgebase.macrium.com/display/KNOWX/VSS+fails+due+to+modification+by+3rd+party+software

"vssadmin list writers" will show what others there are. Nothing popped
out as obvious for Reflect's VSS writer. The names aren't all obvious. "vssadmin list providers" only shows me the one from Microsoft. At HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Providers in
the registry, there is only 1 entry (showing the MS provider). Perhaps
a VSS provider can register themself at the time they are called.

And for an even more esoteric cause:

There are spurious errors that remain unresolved that logs won't reveal
the causes. They'll reveal an error code, but not the causes. For
example, gamma radiation can significantly disrupt the circuitry in a
computer: ionizing atoms, flipping bits in memory, causing random
errors. I didn't bother to check solar history to see if there was a
recent gamma burst from the Sun, or if Earth happened to be in the
sweeping path of a pulsar. I haven't seen "radiation hardened
computers" for sale to consumers, but then I never looked since I wasn't
going to spend $200K to $300K on one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12/1/2024 8:15 PM, VanguardLH wrote:

And for an even more esoteric cause:

There are spurious errors that remain unresolved that logs won't reveal
the causes. They'll reveal an error code, but not the causes. For
example, gamma radiation can significantly disrupt the circuitry in a computer: ionizing atoms, flipping bits in memory, causing random
errors. I didn't bother to check solar history to see if there was a
recent gamma burst from the Sun, or if Earth happened to be in the
sweeping path of a pulsar. I haven't seen "radiation hardened
computers" for sale to consumers, but then I never looked since I wasn't going to spend $200K to $300K on one.

Normally, I would cast scorn on this idea, but I did have
my *wrist watch* disturbed while it was sitting on my desk
here. I wasn't watching it, but the settings were "all screwy"
and the battery was still good.

Normal energy cosmic rays, shouldn't be able to do that
on 3 micron CMOS. CMOS has high noise margins to begin
with, as logic goes, and large geometry means that
a cosmic ray, at most, should upset one bit kind of thing,
not blow the bloody doors off it.

So something energetic happened, at a guess.

Maybe a cosmic ray went through the watch sideways,
but even that would not flip everything.

The metal of the watch, should give some protection
from an RF attack (say, a microwave beam).

That's the reason I now have two wrist watches sitting
on the desk. Yet another experiment, to see if there is
ever a next time for one of these, both watches are
kicked around or not. Other devices in the room, were
not affected. It's not like all sorts of stuff dropped
at the same time.

*******

With regard to the OPs device, it has 50 bytes of error
syndrome to protect 512 bytes of data. Even if hit with
a chain saw, it should be able to correct the error
and reconstitute the data. It should still be able to boot.

If you subjected a flash device to an XRay source, you
might be able to erase part of it that way. But how many
portable XRay sources do you have around the house ?
I don't think I have anything here, to give me 40kV to work
with. The best I can do is around 15kV.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul wrote:

On Sun, 12/1/2024 8:15 PM, VanguardLH wrote:

And for an even more esoteric cause:

There are spurious errors that remain unresolved that logs won't reveal
the causes. They'll reveal an error code, but not the causes. For
example, gamma radiation can significantly disrupt the circuitry in a
computer: ionizing atoms, flipping bits in memory, causing random
errors. I didn't bother to check solar history to see if there was a
recent gamma burst from the Sun, or if Earth happened to be in the
sweeping path of a pulsar. I haven't seen "radiation hardened
computers" for sale to consumers, but then I never looked since I wasn't
going to spend $200K to $300K on one.

Normally, I would cast scorn on this idea, but I did have
my *wrist watch* disturbed while it was sitting on my desk
here. I wasn't watching it, but the settings were "all screwy"
and the battery was still good.

Normal energy cosmic rays, shouldn't be able to do that
on 3 micron CMOS. CMOS has high noise margins to begin
with, as logic goes, and large geometry means that
a cosmic ray, at most, should upset one bit kind of thing,
not blow the bloody doors off it.

So something energetic happened, at a guess.

Maybe a cosmic ray went through the watch sideways,
but even that would not flip everything.

The metal of the watch, should give some protection
from an RF attack (say, a microwave beam).

That's the reason I now have two wrist watches sitting
on the desk. Yet another experiment, to see if there is
ever a next time for one of these, both watches are
kicked around or not. Other devices in the room, were
not affected. It's not like all sorts of stuff dropped
at the same time.

*******

With regard to the OPs device, it has 50 bytes of error
syndrome to protect 512 bytes of data. Even if hit with
a chain saw, it should be able to correct the error
and reconstitute the data. It should still be able to boot.

If you subjected a flash device to an XRay source, you
might be able to erase part of it that way. But how many
portable XRay sources do you have around the house ?
I don't think I have anything here, to give me 40kV to work
with. The best I can do is around 15kV.

Paul

Sticky tape?
https://physicsworld.com/a/sticky-tape-takes-x-ray-images/
It needs a vacuum though, otherwise it just ionizes the air.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul wrote:

On Sun, 12/1/2024 9:18 AM, LiverpoolFC Fan wrote:

On 01/12/2024 14:10, Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

If you are imaging the C: drive while the system is running then not
everything is copied because some files are protected by the operating
system while they are used.

You can create a rescue media which can be used to boot-up the machine
to clone/image the system disk.

You asked how long this has been going on. The short answer is as long
as "MOST" imaging software were created. I never backup the system disk
while the machine is running. Rescue Media is what I use 100% of the time. >>

Incorrect.

Most all of the backup softwares use VSS during a backup.
This is a mechanism for doing "hot" backups of the C: partition
in particular.

The way this works, is softwares with issues (like the OS), they
have to have a "provider" to quiesce certain files. When VSS is
triggered and a shadow copy made (a "frozen" snapshot of the OS partition), there is a ten second interval, where the providers are told it is
time to quiesce. And that's when the shadow is made.

Some files have not been getting backed up. Perhaps the Windows.db or Windows.edb of the SearchIndexer did not get backed up. I don't
think the Pagefile.sys gets backed up. Even though the traffic level
on that file is a *lot* different than in past OSes, it is unlikely
to be a good candidate for the design.

Thus, you will find things missing from a backup. But these are
also not "critical" items. If the pagefile.sys was replaced with
a like-sized file of zeros, you'd never notice at boot time.

And the Windows.edb can be regenerated. As a derived file, it's
not a critical file.

As the system gets more features involving virtualization,
it's hard to comment on the "things you can't see". Maybe
something like that is causing the OPs problem.

But generally speaking, the OS and the applications
are familiar with VSS and the shadow copy system and this
is why we're not freaking out about making backups
while the computer is running.

*******

Now, *if* a users computer has a problem, such as the VSS subsystem
is down, then on Macrium at least, it switches to PSS and that
is its own invention. That likely would be missing some additional files.

I would interpret the OPs message as an indication that
something is wrong with VSS, as a first approximation.

Shadows can be persistent or non-persistent. Macrium may use
persistent shadows for "incremental forever" or "incremental".
There have definitely been cases of some competing backup
products, using up all 64 shadow slots and running out! And
that would represent a failure of sorts. A design failure
by the backup software maker.

vssadmin list shadows

On WinXP, the difference was supposed to be, it did not support
persistent shadows, and you could have a shadow long enough to
make a full backup without a problem. I wasn't always convinced
that it did not have persistent shadows, as sometimes the shadow
list had an entry or two that should not have been there.

Paul

Everything looks OK. The image file is slightly larger than the previous
one; the log consists of one line - image successful; "vssadmin list
shadows" shows two entries, both ok; Volume Shadow Copy service is set
to manual; chkdsk /r shows no problems.

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer <ed@somewhere.in.the.uk> wrote:
[...]

Everything looks OK. The image file is slightly larger than the previous
one; the log consists of one line - image successful; ...

You probably mean the message in the popup window of the current
backup, or in the 'Logs' *list*. But the actual log should be much
longer (not that I expect more relevant info there):

'Logs' tab -> double click the relevant entry in the list (or
right-click it -> View)

(this is for the last free version, 8.0.7783)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Frank Slootweg wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:
[...]

Everything looks OK. The image file is slightly larger than the previous
one; the log consists of one line - image successful; ...

You probably mean the message in the popup window of the current
backup, or in the 'Logs' *list*. But the actual log should be much
longer (not that I expect more relevant info there):

'Logs' tab -> double click the relevant entry in the list (or
right-click it -> View)

(this is for the last free version, 8.0.7783)

That's the stuff that rolls up the screen during runtime. And yes, all
OK. And no mention of the warning I saw (which, incidentally, had the
option to "not show again"; as if it were purely informational).

I'm on version 8.0.7783 also. So it's not a recent update.
So then, why haven't I had that display previously? Strange occurrence.

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

RWQgQ3J5ZXIgd3JvdGU6DQo+IEZyYW5rIFNsb290d2VnIHdyb3RlOg0KPj4gRWQgQ3J5ZXIg PGVkQHNvbWV3aGVyZS5pbi50aGUudWs+IHdyb3RlOg0KPj4gWy4uLl0NCj4+DQo+Pj4gRXZl cnl0aGluZyBsb29rcyBPSy4gVGhlIGltYWdlIGZpbGUgaXMgc2xpZ2h0bHkgbGFyZ2VyIHRo YW4gdGhlIHByZXZpb3VzDQo+Pj4gb25lOyB0aGUgbG9nIGNvbnNpc3RzIG9mIG9uZSBsaW5l IC0gaW1hZ2Ugc3VjY2Vzc2Z1bDsgLi4uDQo+Pg0KPj4gwqDCoCBZb3UgcHJvYmFibHkgbWVh biB0aGUgbWVzc2FnZSBpbiB0aGUgcG9wdXAgd2luZG93IG9mIHRoZSBjdXJyZW50DQo+PiBi YWNrdXAsIG9yIGluIHRoZSAnTG9ncycgKmxpc3QqLiBCdXQgdGhlIGFjdHVhbCBsb2cgc2hv dWxkIGJlIG11Y2gNCj4+IGxvbmdlciAobm90IHRoYXQgSSBleHBlY3QgbW9yZSByZWxldmFu dCBpbmZvIHRoZXJlKToNCj4+DQo+PiDCoMKgICdMb2dzJyB0YWIgLT4gZG91YmxlIGNsaWNr IHRoZSByZWxldmFudCBlbnRyeSBpbiB0aGUgbGlzdCAob3INCj4+IHJpZ2h0LWNsaWNrIGl0 IC0+IFZpZXcpDQo+Pg0KPj4gKHRoaXMgaXPCoCBmb3IgdGhlIGxhc3QgZnJlZSB2ZXJzaW9u LCA4LjAuNzc4MykNCj4gDQo+IFRoYXQncyB0aGUgc3R1ZmYgdGhhdCByb2xscyB1cCB0aGUg c2NyZWVuIGR1cmluZyBydW50aW1lLiBBbmQgeWVzLCBhbGwgDQo+IE9LLiBBbmQgbm8gbWVu dGlvbiBvZiB0aGUgd2FybmluZyBJIHNhdyAod2hpY2gsIGluY2lkZW50YWxseSwgaGFkIHRo ZSANCj4gb3B0aW9uIHRvICJub3Qgc2hvdyBhZ2FpbiI7IGFzIGlmIGl0IHdlcmUgcHVyZWx5 IGluZm9ybWF0aW9uYWwpLg0KPiANCj4gSSdtIG9uIHZlcnNpb24gOC4wLjc3ODMgYWxzby4g U28gaXQncyBub3QgYSByZWNlbnQgdXBkYXRlLg0KPiBTbyB0aGVuLCB3aHkgaGF2ZW4ndCBJ IGhhZCB0aGF0IGRpc3BsYXkgcHJldmlvdXNseT8gU3RyYW5nZSBvY2N1cnJlbmNlLg0KPiAN Cj4gRWQNCj4gDQoNCmh0dHBzOi8vd3d3LmRyb3Bib3guY29tL3NjbC9maS9zNzB5NnBpZnpi MGU2OXd0bGxwb2svTWFjcml1bS1tc2cuanBnP3Jsa2V5PTc1a210Y3JpcHp1MDE4ZThmcTg0 bnZuM3AmZT0xJmRsPTANClRoZSBNYWNyaXVtIG1lc3NhZ2UgYm94Lg0KDQpFZA0K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer <ed@somewhere.in.the.uk> wrote:

Ed Cryer wrote:

Frank Slootweg wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:
[...]

Everything looks OK. The image file is slightly larger than the previous >>> one; the log consists of one line - image successful; ...

   You probably mean the message in the popup window of the current
backup, or in the 'Logs' *list*. But the actual log should be much
longer (not that I expect more relevant info there):

   'Logs' tab -> double click the relevant entry in the list (or
right-click it -> View)

(this is  for the last free version, 8.0.7783)

That's the stuff that rolls up the screen during runtime. And yes, all
OK. And no mention of the warning I saw (which, incidentally, had the option to "not show again"; as if it were purely informational).

I'm on version 8.0.7783 also. So it's not a recent update.
So then, why haven't I had that display previously? Strange occurrence.
^M
Ed

https://www.dropbox.com/scl/fi/s70y6pifzb0e69wtllpok/Macrium-msg.jpg?rlkey=75kmtcripzu018e8fq84nvn3p&e=1&dl=0
The Macrium message box.

[Re-typed text of JPG file:]

"Macrium Reflect

Backup may not include all required partitions

It appears as if you are trying to create a backup of the operating system.

The current selection may not include all partitions neccessary for this.

Preceed anyway?


[ ] Do not show this again [OK] [Cancel]"

Ah, this *is* a familiar one and a bit different from what you said in
your OP, which was "a warning that parts of the operating system
wouldn't be saved", while the actual warning talks about not including
all *partitions* (not "parts").

I've only seen this warning message when creating or modifying a
Backup Definition file (Do you use a Backup Definition File?), but
perhaps it can also occur during other situations.

Anyway, as you said "I produced an image of my C disk today", the
warning message is exactly telling you that: You didn't include all the partitions needed to create a backup of your operating system, because
you didn't include the other 'boot' recovery, etc. partitions.

So if you tell us how exactly your perform your image backup, i.e. the detailed steps from starting Macrium Reflect till the actual warning
message occurs, we might be able to determine why you get the message.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 12/2/2024 1:40 PM, Frank Slootweg wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:

Ed Cryer wrote:

Frank Slootweg wrote:

Ed Cryer <ed@somewhere.in.the.uk> wrote:
[...]

Everything looks OK. The image file is slightly larger than the previous >>>>> one; the log consists of one line - image successful; ...

   You probably mean the message in the popup window of the current
backup, or in the 'Logs' *list*. But the actual log should be much
longer (not that I expect more relevant info there):

   'Logs' tab -> double click the relevant entry in the list (or
right-click it -> View)

(this is  for the last free version, 8.0.7783)

That's the stuff that rolls up the screen during runtime. And yes, all
OK. And no mention of the warning I saw (which, incidentally, had the
option to "not show again"; as if it were purely informational).

I'm on version 8.0.7783 also. So it's not a recent update.
So then, why haven't I had that display previously? Strange occurrence.
^M
Ed

https://www.dropbox.com/scl/fi/s70y6pifzb0e69wtllpok/Macrium-msg.jpg?rlkey=75kmtcripzu018e8fq84nvn3p&e=1&dl=0
The Macrium message box.

[Re-typed text of JPG file:]

"Macrium Reflect

Backup may not include all required partitions

It appears as if you are trying to create a backup of the operating system.

The current selection may not include all partitions neccessary for this.

Preceed anyway?

[ ] Do not show this again [OK] [Cancel]"

Ah, this *is* a familiar one and a bit different from what you said in
your OP, which was "a warning that parts of the operating system
wouldn't be saved", while the actual warning talks about not including
all *partitions* (not "parts").

I've only seen this warning message when creating or modifying a
Backup Definition file (Do you use a Backup Definition File?), but
perhaps it can also occur during other situations.

Anyway, as you said "I produced an image of my C disk today", the
warning message is exactly telling you that: You didn't include all the partitions needed to create a backup of your operating system, because
you didn't include the other 'boot' recovery, etc. partitions.

So if you tell us how exactly your perform your image backup, i.e. the detailed steps from starting Macrium Reflect till the actual warning
message occurs, we might be able to determine why you get the message.

On a GPT partitioned disk

ESP EFI System Partition (FAT32) Has boot materials (Microsoft folder, Ubuntu folder, ...)

C: OS Partition (NTFS 4K cluster)

Recovery Partition Has WinRE.wim file, and is marked as Required (Required in a backup too)

The Required flag seems to correlate with GPT Attribute 0x0000000000000001 <=== trailing bit set

But not all the partitions are marked as Required. Using our architecture
hat, we guess that the ESP is defacto-required. We guess that C:
is defacto-required. This leaves Recovery partition to receive an explicit Required flag, so it gets picked up in a backup. Not all OS installations
have a System Reserved or a Recovery Partition. But if it exists, it will
be marked as Required.

*******

This is a Recovery Partition

DISKPART> select partition 4

Partition 4 is now the selected partition.

DISKPART> detail partition

Partition 4
Type : de94bba4-06d1-4d40-a16a-bfd50179d6ac
Hidden : Yes
Required: Yes <=== Thus, a good idea to include next to C: in a backup
Attrib : 0X0000000000000001
Offset in Bytes: 127604359168

Volume ### Ltr Label Fs Type Size Status Info
---------- --- ----------- ----- ---------- ------- --------- -------- * Volume 4 NTFS Partition 649 MB Healthy Hidden

*******

[Picture]

https://i.postimg.cc/N0hDy3Wc/partition-sets.gif

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that
I've not seen before; a warning that parts of the operating system
wouldn't be saved.
How long has this been going on?

Ed

The C drive has 3 partitions
PQSERVICE
SYSTEM RESERVED
Win-10

All previous Macrium images contain all three. The latest contains only
two, the SYSTEM RESERVED (100MB) isn't saved.
That partition contains boot information in files dated on the day the
OS was first initialised; apart from, that is, an empty $RECYCLE.BIN and
an empty System Volume Information folder.

Therefore, I can do a full system restore from the latest image without
any loss or corruption.

The question remains; when did this change in Macrium Reflect come in?
What caused it? Some change in my system or an update to the program? I
suspect the latter, and wait for others to report the message appearing
on their systems.

P.S. on the merits of scientific method.
God bless David Hume; and God bless his Treatise of Human Nature. Let's
get beyond subjective experience, beyond battling for personal favourite explanations, beyond faith and prejudice and myopic nepotistic intolerance. Human reason with experimentation; suck it and see if it works >>>>
pragmatism.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/12/2024 19:28, Ed Cryer wrote:

Therefore, I can do a full system restore from the latest image without
any loss or corruption.

IT'S ALL VERY WELL BUT DOES THE SYSTEM STILL BOOT-UP AFTER YOU HAVE
RESTORED FROM THE BACKUPS? MANY TIMES PEOPLE REPORT THAT THEIR SYSTEM
CAN'T BOOT-UP FROM IMAGES AND SO THEY RESORT TO COMPLETE INSTALLATION OF
OS AND ALL APPLICATIONS THAT THEY ARE USING.

THEIR PERSONAL DATA IS GONE FOREVER BECAUSE THEY RELIED ON THEIR BACK-UP SCHEDULE THAT THEY HAD DEVISED 40 YEARS AGO!! THEY FORGOT THE BASIC HEX
ROUTINE OF TESTING THE BACK-UP RESTORATION.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Never Trust Backups wrote:

On 03/12/2024 19:28, Ed Cryer wrote:

Therefore, I can do a full system restore from the latest image without
any loss or corruption.

IT'S ALL VERY WELL BUT DOES THE SYSTEM STILL BOOT-UP AFTER YOU HAVE
RESTORED FROM THE BACKUPS? MANY TIMES PEOPLE REPORT THAT THEIR SYSTEM
CAN'T BOOT-UP FROM IMAGES AND SO THEY RESORT TO COMPLETE INSTALLATION OF
OS AND ALL APPLICATIONS THAT THEY ARE USING.

THEIR PERSONAL DATA IS GONE FOREVER BECAUSE THEY RELIED ON THEIR BACK-UP SCHEDULE THAT THEY HAD DEVISED 40 YEARS AGO!! THEY FORGOT THE BASIC HEX ROUTINE OF TESTING THE BACK-UP RESTORATION.

Hello William James.
Or should that be
HELLO WILLIAM JAMES?
The latter seems exceptionally Narcissitic to me ; like the grunts of
some low-life who has to shout to ensure any attention to his sayings.

What reasons do you have to suggest that it won't boot? I can see none.
And since you made the charges, it's up to you to favour us with your reasonings.

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 12/3/2024 1:16 PM, ...w¡ñ§±¤ñ wrote:

Paul wrote on 12/2/24 7:20 PM:

     https://i.postimg.cc/N0hDy3Wc/partition-sets.gif

    Paul

With Macrium I also choose the MSR(locsted after System, prior to Windows and WinRE partitions.

Macrium when MSR is present auto selects MSR and Recovery when choosing the image selected disks option. When choosing the option to image the partitions required to backup and restore Windows - the MSR and WinRE require user selection.

[Picture]

https://i.postimg.cc/3Rqjth4W/partition-sets-and-Macrium.gif

It's pretty hard to write a cohesive "story" about the OS, when
the MSR partition is

1) Not shown in Disk Management. <=== Why? Show it! This upsets the partition numbering FFS.
2) Does not have a File System.
3) Does not have a 1:1 relationship with installed OSes.
If you have two copies of Windows, there is no MSR in front of the second OS.

The only thing left, is the MSR has some cryptographic purpose.

And, I can tell you, that the MSR causes no end of problems in Linux gparted. When you want to move things in gparted, gparted is "careful to do a post-move verification of *file system*, to detect damage caused by GParted". It finds no file system. It then freaks out and now anything to the left of the MSR,
can't be moved. Windows doesn't move partitions. Linux can't move an MSR. Oh, joy.

*******

DISKPART> list partition

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 1024 KB
Partition 2 Reserved 16 MB 101 MB <=== the bastard partition
Partition 3 Primary 118 GB 117 MB
Partition 4 Recovery 649 MB 118 GB
Partition 5 Primary 128 GB 119 GB
Partition 6 Recovery 1025 MB 248 GB
Partition 7 Primary 682 GB 249 GB

DISKPART> select partition 2

Partition 2 is now the selected partition.

DISKPART> detail partition

Partition 2
Type : e3c9e316-0b5c-4db8-817d-f92df00215ae
Hidden : Yes
Required: No <=== For OS purpose No, for disk maintenance Yes Attrib : 0000000000000000
Offset in Bytes: 105906176

There is no volume associated with this partition. <===

DISKPART>

*******

https://en.wikipedia.org/wiki/Microsoft_Reserved_Partition

"Formerly, on disks formatted using the master boot record (MBR) partition layout,
certain software components used hidden sectors of the disk for data storage purposes.
For example, the Logical Disk Manager (LDM), on dynamic disks, stores metadata
in a 1 MB area at the end of the disk which is not allocated to any partition.[3]

The UEFI specification does not allow hidden sectors on GPT-formatted disks.

Microsoft reserves a chunk of disk space using this MSR partition type,
to provide an alternative data storage space for such software components
which previously may have used hidden sectors on MBR formatted disks.
Small, special-purpose partitions can be allocated from a portion of
the space reserved in the MSR partition."

"The Microsoft-recommended size of MSR:

Windows 7 128 MB[4]
Windows 8 & 8.1 128 MB[5]
Windows 10 16 MB[6] "

*******

On the one hand, we have the claim it is "The Last Cylinder".

Yet the table of values, what does that pattern mean ?
Half a story, is no story at all.

128MB of space is not a last cylinder. And the GPT partition table
primary and secondary are not 128MB either.

But at least only having one MSR per disk drive, makes a little more sense now. It seems to be a disk level structure and not an OS level structure. Maybe.
Or maybe not.

And as a mystery meat, we'll be backing it up I guess.

*******

Windows 7 backup does not appear to back that up. Hmmm. The System Image
it made, it ignored the 16MB space. And none of the XML files, contain
anything of interest. The 6MB file is a declaration of system files
at the file level. Nothing in the "noise section" of the backup, equates
to an encoded MSR content.

Directory of D:\WindowsImageBackup\WALLACE\Backup 2024-12-03 222612 A Smart Copy, only Busy clusters recorded...

Tue, 12/03/2024 05:29 PM 60,817,408 Esp.vhdx ESP
Tue, 12/03/2024 05:29 PM 70,290,243,584 0bd6166a-0836-4041-891c-792df2c72abd.vhdx C:
Tue, 12/03/2024 05:29 PM 616,562,688 c3bc5ab1-c5f0-4dae-838c-751ef868e237.vhdx Recovery Partition (WinRE sized)

Tue, 12/03/2024 05:29 PM 776 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_AdditionalFilesc3b9f3c7-5e52-4d5e-8b20-19adc95a34c7.xml
Tue, 12/03/2024 05:29 PM 18,948 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Components.xml
Tue, 12/03/2024 05:29 PM 6,884 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_RegistryExcludes.xml
Tue, 12/03/2024 05:29 PM 10,728 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writer4dc3bdd4-ab48-4d07-adb0-3bee2926fd7f.xml
Tue, 12/03/2024 05:29 PM 1,488 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writer542da469-d3e1-473c-9f4f-7847f01fc64f.xml
Tue, 12/03/2024 05:29 PM 1,484 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writera6ad56c2-b509-4e6c-bb19-49d8f43532f0.xml
Tue, 12/03/2024 05:29 PM 2,940 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writerafbab4a2-367d-4d15-a586-71dbb18f8485.xml
Tue, 12/03/2024 05:29 PM 7,962 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writerbe000cbe-11fe-4426-9c58-531aa6355fc4.xml
Tue, 12/03/2024 05:29 PM 5,402 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writercd3f2362-8bef-46c7-9181-d62844cdc0b2.xml
Tue, 12/03/2024 05:29 PM 6,589,944 7a51ce53-7e37-4e53-a0e3-a8f4f1a54b4b_Writere8132975-6f93-4464-a53e-1050253ae220.xml
Tue, 12/03/2024 05:29 PM 1,528 BackupSpecs.xml

14 File(s) 70,974,271,764 bytes
2 Dir(s) 22,100,594,688 bytes free

An inconclusive story. OK to back it up. But don't know why.

Sure, when the Windows 7 (W11 Edition) backup is restored, the restoration process
could create an all-zeros 16MB area if it wants. That's possible,
but is not a "preservation" of whatever the content was before.
If there was a Veritas Dynamic Disks declaration, that would be missing.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 12/3/2024 2:28 PM, Ed Cryer wrote:

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that I've not seen before; a warning that parts of the operating system wouldn't be saved.
How long has this been going on?

Ed

The C drive has 3 partitions
PQSERVICE
SYSTEM RESERVED
Win-10

All previous Macrium images contain all three. The latest contains only two, the SYSTEM RESERVED (100MB) isn't saved.
That partition contains boot information in files dated on the day the OS was first initialised; apart from, that is, an empty $RECYCLE.BIN and an empty System Volume Information folder.

Therefore, I can do a full system restore from the latest image without any loss or corruption.

The question remains; when did this change in Macrium Reflect come in? What caused it? Some change in my system or an update to the program? I suspect the latter, and wait for others to report the message appearing on their systems.

That pattern is a W10-over-W7 installation.

The PQSERVICE might be 15GB or so, and contain Windows 7 Factory.

I have a clean Win10 install on MSDOS partitioning, and it looks like this.
and I know that I can't quite reproduce your setup. Maybe my laptop
would come the closest, but I can't remember for sure whether that
was a Clean, or W10-over-W7 install.

[Picture]

https://i.postimg.cc/HWqMPBxZ/W10-MSDOS-Partition-WAFFLES-Samsung-256.gif

OK, this one is a bit closer to a W10-over-W7 with MSDOS partitioning (LAPTOP). The System Reserved is on the right side of C: and the upgrade process
(of creating additional System Reserved and not cleaning up the decommissioned System Reserved), is not possible for the Windows Update logic to handle.
The System Reserved was made larger for the WinRE larger size issue.
Since there are only four primary partitions on MSDOS and (snicker) I used
them all up, Windows is prevented from making a mess.

[Picture]

https://i.postimg.cc/FRnq01j6/LAPTOP-partition-table-MSDOS.gif

While that is closer to yours, it's not a perfect match by any stretch.
It's just in the same ballpark. I didn't take a PQEDIT32 picture,
as the boot flag will be where the "boot" label is recorded in the second picture.

*******

Any time a partition size is disturbed, you should make a new Backup settings file or edit the existing one. That's one of the problems of living in a dynamic environment, where you don't control everything. You have to notice when something is broken, then consider how many backup images
have been broken by the change (like in the middle of a Full+Incrementals set), then do
whatever is necessary to kick off a new set of backups, with
amended partition info. Whatever it happens to want.

Complete sets of old backups are not broken as such. If you had
to restore to a brand new hard drive, the thing would boot and so on.

And if you restore to a partition which is smaller, Macrium does not
mind, unless the total files won't fit in the partition :-) Macrium
support resize-on-restore, a handy feature.

Should you test the ability to boot a restoration ?

Yes.

And the "spare drive" you purchase for this test case,
of restoring to a new drive, that "spare drive" functions
as your "replacement drive" when the other one wears out.
It's not wasted money, the spare drive will come in handy
when the time comes. If you sell the computer, you can sell
the spare with it, at recovery cost price.

*******

If you still have a copy of "ImgToVHD.exe" that Macrium used to have,
that can convert a "small" MRIMG (a full backup) to a VHD file.
The VHD file can be mounted in Windows in Disk Management, and
then you can use ordinary tools for measuring the size of partitions
and so on. An MRIMG can also be mounted in Windows, for forensic
purposes, using the Macrium option to mount an image. There should
generally be ways of gaining forensic analysis capability, to
compare the older sets of backups, to any newer sets, if the need arises.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paul wrote:

On Tue, 12/3/2024 2:28 PM, Ed Cryer wrote:

Ed Cryer wrote:

I produced an image of my C disk today, and got an initial message that I've not seen before; a warning that parts of the operating system wouldn't be saved.
How long has this been going on?

Ed

The C drive has 3 partitions
PQSERVICE
SYSTEM RESERVED
Win-10

All previous Macrium images contain all three. The latest contains only two, the SYSTEM RESERVED (100MB) isn't saved.
That partition contains boot information in files dated on the day the OS was first initialised; apart from, that is, an empty $RECYCLE.BIN and an empty System Volume Information folder.

Therefore, I can do a full system restore from the latest image without any loss or corruption.

The question remains; when did this change in Macrium Reflect come in? What caused it? Some change in my system or an update to the program? I suspect the latter, and wait for others to report the message appearing on their systems.

That pattern is a W10-over-W7 installation.

The PQSERVICE might be 15GB or so, and contain Windows 7 Factory.

I have a clean Win10 install on MSDOS partitioning, and it looks like this. and I know that I can't quite reproduce your setup. Maybe my laptop
would come the closest, but I can't remember for sure whether that
was a Clean, or W10-over-W7 install.

[Picture]

https://i.postimg.cc/HWqMPBxZ/W10-MSDOS-Partition-WAFFLES-Samsung-256.gif

OK, this one is a bit closer to a W10-over-W7 with MSDOS partitioning (LAPTOP).
The System Reserved is on the right side of C: and the upgrade process
(of creating additional System Reserved and not cleaning up the decommissioned
System Reserved), is not possible for the Windows Update logic to handle.
The System Reserved was made larger for the WinRE larger size issue.
Since there are only four primary partitions on MSDOS and (snicker) I used them all up, Windows is prevented from making a mess.

[Picture]

https://i.postimg.cc/FRnq01j6/LAPTOP-partition-table-MSDOS.gif

While that is closer to yours, it's not a perfect match by any stretch.
It's just in the same ballpark. I didn't take a PQEDIT32 picture,
as the boot flag will be where the "boot" label is recorded in the second picture.

*******

Any time a partition size is disturbed, you should make a new Backup settings file or edit the existing one. That's one of the problems of living in a dynamic environment, where you don't control everything. You have to notice when something is broken, then consider how many backup images
have been broken by the change (like in the middle of a Full+Incrementals set), then do
whatever is necessary to kick off a new set of backups, with
amended partition info. Whatever it happens to want.

Complete sets of old backups are not broken as such. If you had
to restore to a brand new hard drive, the thing would boot and so on.

And if you restore to a partition which is smaller, Macrium does not
mind, unless the total files won't fit in the partition :-) Macrium
support resize-on-restore, a handy feature.

Should you test the ability to boot a restoration ?

Yes.

And the "spare drive" you purchase for this test case,
of restoring to a new drive, that "spare drive" functions
as your "replacement drive" when the other one wears out.
It's not wasted money, the spare drive will come in handy
when the time comes. If you sell the computer, you can sell
the spare with it, at recovery cost price.

*******

If you still have a copy of "ImgToVHD.exe" that Macrium used to have,
that can convert a "small" MRIMG (a full backup) to a VHD file.
The VHD file can be mounted in Windows in Disk Management, and
then you can use ordinary tools for measuring the size of partitions
and so on. An MRIMG can also be mounted in Windows, for forensic
purposes, using the Macrium option to mount an image. There should
generally be ways of gaining forensic analysis capability, to
compare the older sets of backups, to any newer sets, if the need arises.

Paul

Hi, Paul

I have the full solution now, and it's so simple that I feel almost
ashamed of myself for not having solved it earlier without having to
post here.
You've been a good friend over the years, so I'll state it baldly.
The GUI of Macrium Reflect didn't have the SYSTEM RESERVED partition
ticked; and I didn't originally notice.
As to why it wasn't ticked, I can only speculate. My best guess is some
slip of my hand.
Now that I've ticked it, the GUI always presents with it already ticked.

Ed

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12/4/2024 5:23 AM, Ed Cryer wrote:

Hi, Paul

I have the full solution now, and it's so simple that I feel almost ashamed of myself for not having solved it earlier without having to post here.
You've been a good friend over the years, so I'll state it baldly.
The GUI of Macrium Reflect didn't have the SYSTEM RESERVED partition ticked; and I didn't originally notice.
As to why it wasn't ticked, I can only speculate. My best guess is some slip of my hand.
Now that I've ticked it, the GUI always presents with it already ticked.

Ed

It is an interface that invites mischief :-)

And I'm pretty sure there are naughty things we
could do without too much trouble (while backing
you Veritas Dynamic Disks perhaps).

That's why the program has an option on the left
to "back up everything on the machine". That is
for the really lazy people.

"Image selected disks on the computer"

The ticky box on the left of each row in the
resulting dialog, allows relatively quickly
selecting everything. The dialog is also
clever enough to throw up a warning, when you
include the backup drive in the drives to be
backed up :-)

That can make an awfully big file though.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Li4ud8Khw7HCp8KxwqTDsSB3cm90ZToNCj4gRWQgQ3J5ZXIgd3JvdGUgb24gMTIvNC8yNCAz OjIzIEFNOg0KPj4gUGF1bCB3cm90ZToNCj4+PiBPbiBUdWUsIDEyLzMvMjAyNCAyOjI4IFBN LCBFZCBDcnllciB3cm90ZToNCj4+Pj4gRWQgQ3J5ZXIgd3JvdGU6DQo+Pj4+PiBJIHByb2R1 Y2VkIGFuIGltYWdlIG9mIG15IEMgZGlzayB0b2RheSwgYW5kIGdvdCBhbiBpbml0aWFsIG1l c3NhZ2UgDQo+Pj4+PiB0aGF0IEkndmUgbm90IHNlZW4gYmVmb3JlOyBhIHdhcm5pbmcgdGhh dCBwYXJ0cyBvZiB0aGUgb3BlcmF0aW5nIA0KPj4+Pj4gc3lzdGVtIHdvdWxkbid0IGJlIHNh dmVkLg0KPj4+Pj4gSG93IGxvbmcgaGFzIHRoaXMgYmVlbiBnb2luZyBvbj8NCj4+Pj4+DQo+ Pj4+PiBFZA0KPj4+Pg0KPj4+PiBUaGUgQyBkcml2ZSBoYXMgMyBwYXJ0aXRpb25zDQo+Pj4+ IFBRU0VSVklDRQ0KPj4+PiBTWVNURU0gUkVTRVJWRUQNCj4+Pj4gV2luLTEwDQo+Pj4+DQo+ Pj4+IEFsbCBwcmV2aW91cyBNYWNyaXVtIGltYWdlcyBjb250YWluIGFsbCB0aHJlZS4gVGhl IGxhdGVzdCBjb250YWlucyANCj4+Pj4gb25seSB0d28sIHRoZSBTWVNURU0gUkVTRVJWRUQg KDEwME1CKSBpc24ndCBzYXZlZC4NCj4+Pj4gVGhhdCBwYXJ0aXRpb24gY29udGFpbnMgYm9v dCBpbmZvcm1hdGlvbiBpbiBmaWxlcyBkYXRlZCBvbiB0aGUgZGF5IA0KPj4+PiB0aGUgT1Mg d2FzIGZpcnN0IGluaXRpYWxpc2VkOyBhcGFydCBmcm9tLCB0aGF0IGlzLCBhbiBlbXB0eSAN Cj4+Pj4gJFJFQ1lDTEUuQklOIGFuZCBhbiBlbXB0eSBTeXN0ZW0gVm9sdW1lIEluZm9ybWF0 aW9uIGZvbGRlci4NCj4+Pj4NCj4+Pj4gVGhlcmVmb3JlLCBJIGNhbiBkbyBhIGZ1bGwgc3lz dGVtIHJlc3RvcmUgZnJvbSB0aGUgbGF0ZXN0IGltYWdlIA0KPj4+PiB3aXRob3V0IGFueSBs b3NzIG9yIGNvcnJ1cHRpb24uDQo+Pj4+DQo+Pj4+IFRoZSBxdWVzdGlvbiByZW1haW5zOyB3 aGVuIGRpZCB0aGlzIGNoYW5nZSBpbiBNYWNyaXVtIFJlZmxlY3QgY29tZSANCj4+Pj4gaW4/ IFdoYXQgY2F1c2VkIGl0PyBTb21lIGNoYW5nZSBpbiBteSBzeXN0ZW0gb3IgYW4gdXBkYXRl IHRvIHRoZSANCj4+Pj4gcHJvZ3JhbT8gSSBzdXNwZWN0IHRoZSBsYXR0ZXIsIGFuZCB3YWl0 IGZvciBvdGhlcnMgdG8gcmVwb3J0IHRoZSANCj4+Pj4gbWVzc2FnZSBhcHBlYXJpbmcgb24g dGhlaXIgc3lzdGVtcy4NCj4+Pj4NCj4+Pg0KPj4+IFRoYXQgcGF0dGVybiBpcyBhIFcxMC1v dmVyLVc3IGluc3RhbGxhdGlvbi4NCj4+Pg0KPj4+IFRoZSBQUVNFUlZJQ0UgbWlnaHQgYmUg MTVHQiBvciBzbywgYW5kIGNvbnRhaW4gV2luZG93cyA3IEZhY3RvcnkuDQo+Pj4NCj4+PiBJ IGhhdmUgYSBjbGVhbiBXaW4xMCBpbnN0YWxsIG9uIE1TRE9TIHBhcnRpdGlvbmluZywgYW5k IGl0IGxvb2tzIGxpa2UgDQo+Pj4gdGhpcy4NCj4+PiBhbmQgSSBrbm93IHRoYXQgSSBjYW4n dCBxdWl0ZSByZXByb2R1Y2UgeW91ciBzZXR1cC4gTWF5YmUgbXkgbGFwdG9wDQo+Pj4gd291 bGQgY29tZSB0aGUgY2xvc2VzdCwgYnV0IEkgY2FuJ3QgcmVtZW1iZXIgZm9yIHN1cmUgd2hl dGhlciB0aGF0DQo+Pj4gd2FzIGEgQ2xlYW4sIG9yIFcxMC1vdmVyLVc3IGluc3RhbGwuDQo+ Pj4NCj4+PiDCoMKgwqAgW1BpY3R1cmVdDQo+Pj4NCj4+PiBodHRwczovL2kucG9zdGltZy5j Yy9IV3FNUEJ4Wi9XMTAtTVNET1MtUGFydGl0aW9uLVdBRkZMRVMtIA0KPj4+IFNhbXN1bmct MjU2LmdpZg0KPj4+DQo+Pj4gT0ssIHRoaXMgb25lIGlzIGEgYml0IGNsb3NlciB0byBhIFcx MC1vdmVyLVc3IHdpdGggTVNET1MgcGFydGl0aW9uaW5nIA0KPj4+IChMQVBUT1ApLg0KPj4+ IFRoZSBTeXN0ZW0gUmVzZXJ2ZWQgaXMgb24gdGhlIHJpZ2h0IHNpZGUgb2YgQzogYW5kIHRo ZSB1cGdyYWRlIHByb2Nlc3MNCj4+PiAob2YgY3JlYXRpbmcgYWRkaXRpb25hbCBTeXN0ZW0g UmVzZXJ2ZWQgYW5kIG5vdCBjbGVhbmluZyB1cCB0aGUgDQo+Pj4gZGVjb21taXNzaW9uZWQN Cj4+PiBTeXN0ZW0gUmVzZXJ2ZWQpLCBpcyBub3QgcG9zc2libGUgZm9yIHRoZSBXaW5kb3dz IFVwZGF0ZSBsb2dpYyB0byANCj4+PiBoYW5kbGUuDQo+Pj4gVGhlIFN5c3RlbSBSZXNlcnZl ZCB3YXMgbWFkZSBsYXJnZXIgZm9yIHRoZSBXaW5SRSBsYXJnZXIgc2l6ZSBpc3N1ZS4NCj4+ PiBTaW5jZSB0aGVyZSBhcmUgb25seSBmb3VyIHByaW1hcnkgcGFydGl0aW9ucyBvbiBNU0RP UyBhbmQgKHNuaWNrZXIpIEkgDQo+Pj4gdXNlZA0KPj4+IHRoZW0gYWxsIHVwLCBXaW5kb3dz IGlzIHByZXZlbnRlZCBmcm9tIG1ha2luZyBhIG1lc3MuDQo+Pj4NCj4+PiDCoMKgwqAgW1Bp Y3R1cmVdDQo+Pj4NCj4+PiDCoMKgwqAgaHR0cHM6Ly9pLnBvc3RpbWcuY2MvRlJucTAxajYv TEFQVE9QLXBhcnRpdGlvbi10YWJsZS1NU0RPUy5naWYNCj4+Pg0KPj4+IFdoaWxlIHRoYXQg aXMgY2xvc2VyIHRvIHlvdXJzLCBpdCdzIG5vdCBhIHBlcmZlY3QgbWF0Y2ggYnkgYW55IHN0 cmV0Y2guDQo+Pj4gSXQncyBqdXN0IGluIHRoZSBzYW1lIGJhbGxwYXJrLiBJIGRpZG4ndCB0 YWtlIGEgUFFFRElUMzIgcGljdHVyZSwNCj4+PiBhcyB0aGUgYm9vdCBmbGFnIHdpbGwgYmUg d2hlcmUgdGhlICJib290IiBsYWJlbCBpcyByZWNvcmRlZCBpbiB0aGUgDQo+Pj4gc2Vjb25k IHBpY3R1cmUuDQo+Pj4NCj4+PiAqKioqKioqDQo+Pj4NCj4+PiBBbnkgdGltZSBhIHBhcnRp dGlvbiBzaXplIGlzIGRpc3R1cmJlZCwgeW91IHNob3VsZCBtYWtlIGEgbmV3IEJhY2t1cCAN Cj4+PiBzZXR0aW5ncw0KPj4+IGZpbGUgb3IgZWRpdCB0aGUgZXhpc3Rpbmcgb25lLiBUaGF0 J3Mgb25lIG9mIHRoZSBwcm9ibGVtcyBvZiBsaXZpbmcgaW4gYQ0KPj4+IGR5bmFtaWMgZW52 aXJvbm1lbnQsIHdoZXJlIHlvdSBkb24ndCBjb250cm9sIGV2ZXJ5dGhpbmcuIFlvdSBoYXZl IHRvIA0KPj4+IG5vdGljZQ0KPj4+IHdoZW4gc29tZXRoaW5nIGlzIGJyb2tlbiwgdGhlbiBj b25zaWRlciBob3cgbWFueSBiYWNrdXAgaW1hZ2VzDQo+Pj4gaGF2ZSBiZWVuIGJyb2tlbiBi eSB0aGUgY2hhbmdlIChsaWtlIGluIHRoZSBtaWRkbGUgb2YgYSANCj4+PiBGdWxsK0luY3Jl bWVudGFscyBzZXQpLCB0aGVuIGRvDQo+Pj4gd2hhdGV2ZXIgaXMgbmVjZXNzYXJ5IHRvIGtp Y2sgb2ZmIGEgbmV3IHNldCBvZiBiYWNrdXBzLCB3aXRoDQo+Pj4gYW1lbmRlZCBwYXJ0aXRp b24gaW5mby4gV2hhdGV2ZXIgaXQgaGFwcGVucyB0byB3YW50Lg0KPj4+DQo+Pj4gQ29tcGxl dGUgc2V0cyBvZiBvbGQgYmFja3VwcyBhcmUgbm90IGJyb2tlbiBhcyBzdWNoLiBJZiB5b3Ug aGFkDQo+Pj4gdG8gcmVzdG9yZSB0byBhIGJyYW5kIG5ldyBoYXJkIGRyaXZlLCB0aGUgdGhp bmcgd291bGQgYm9vdCBhbmQgc28gb24uDQo+Pj4NCj4+PiBBbmQgaWYgeW91IHJlc3RvcmUg dG8gYSBwYXJ0aXRpb24gd2hpY2ggaXMgc21hbGxlciwgTWFjcml1bSBkb2VzIG5vdA0KPj4+ IG1pbmQsIHVubGVzcyB0aGUgdG90YWwgZmlsZXMgd29uJ3QgZml0IGluIHRoZSBwYXJ0aXRp b24gOi0pIE1hY3JpdW0NCj4+PiBzdXBwb3J0IHJlc2l6ZS1vbi1yZXN0b3JlLCBhIGhhbmR5 IGZlYXR1cmUuDQo+Pj4NCj4+PiBTaG91bGQgeW91IHRlc3QgdGhlIGFiaWxpdHkgdG8gYm9v dCBhIHJlc3RvcmF0aW9uID8NCj4+Pg0KPj4+IFllcy4NCj4+Pg0KPj4+IEFuZCB0aGUgInNw YXJlIGRyaXZlIiB5b3UgcHVyY2hhc2UgZm9yIHRoaXMgdGVzdCBjYXNlLA0KPj4+IG9mIHJl c3RvcmluZyB0byBhIG5ldyBkcml2ZSwgdGhhdCAic3BhcmUgZHJpdmUiIGZ1bmN0aW9ucw0K Pj4+IGFzIHlvdXIgInJlcGxhY2VtZW50IGRyaXZlIiB3aGVuIHRoZSBvdGhlciBvbmUgd2Vh cnMgb3V0Lg0KPj4+IEl0J3Mgbm90IHdhc3RlZCBtb25leSwgdGhlIHNwYXJlIGRyaXZlIHdp bGwgY29tZSBpbiBoYW5keQ0KPj4+IHdoZW4gdGhlIHRpbWUgY29tZXMuIElmIHlvdSBzZWxs IHRoZSBjb21wdXRlciwgeW91IGNhbiBzZWxsDQo+Pj4gdGhlIHNwYXJlIHdpdGggaXQsIGF0 IHJlY292ZXJ5IGNvc3QgcHJpY2UuDQo+Pj4NCj4+PiAqKioqKioqDQo+Pj4NCj4+PiBJZiB5 b3Ugc3RpbGwgaGF2ZSBhIGNvcHkgb2YgIkltZ1RvVkhELmV4ZSIgdGhhdCBNYWNyaXVtIHVz ZWQgdG8gaGF2ZSwNCj4+PiB0aGF0IGNhbiBjb252ZXJ0IGEgInNtYWxsIiBNUklNRyAoYSBm dWxsIGJhY2t1cCkgdG8gYSBWSEQgZmlsZS4NCj4+PiBUaGUgVkhEIGZpbGUgY2FuIGJlIG1v dW50ZWQgaW4gV2luZG93cyBpbiBEaXNrIE1hbmFnZW1lbnQsIGFuZA0KPj4+IHRoZW4geW91 IGNhbiB1c2Ugb3JkaW5hcnkgdG9vbHMgZm9yIG1lYXN1cmluZyB0aGUgc2l6ZSBvZiBwYXJ0 aXRpb25zDQo+Pj4gYW5kIHNvIG9uLiBBbiBNUklNRyBjYW4gYWxzbyBiZSBtb3VudGVkIGlu IFdpbmRvd3MsIGZvciBmb3JlbnNpYw0KPj4+IHB1cnBvc2VzLCB1c2luZyB0aGUgTWFjcml1 bSBvcHRpb24gdG8gbW91bnQgYW4gaW1hZ2UuIFRoZXJlIHNob3VsZA0KPj4+IGdlbmVyYWxs eSBiZSB3YXlzIG9mIGdhaW5pbmcgZm9yZW5zaWMgYW5hbHlzaXMgY2FwYWJpbGl0eSwgdG8N Cj4+PiBjb21wYXJlIHRoZSBvbGRlciBzZXRzIG9mIGJhY2t1cHMsIHRvIGFueSBuZXdlciBz ZXRzLCBpZiB0aGUgbmVlZCANCj4+PiBhcmlzZXMuDQo+Pj4NCj4+PiDCoMKgwqAgUGF1bA0K Pj4NCj4+IEhpLCBQYXVsDQo+Pg0KPj4gSSBoYXZlIHRoZSBmdWxsIHNvbHV0aW9uIG5vdywg YW5kIGl0J3Mgc28gc2ltcGxlIHRoYXQgSSBmZWVsIGFsbW9zdCANCj4+IGFzaGFtZWQgb2Yg bXlzZWxmIGZvciBub3QgaGF2aW5nIHNvbHZlZCBpdCBlYXJsaWVyIHdpdGhvdXQgaGF2aW5n IHRvIA0KPj4gcG9zdCBoZXJlLg0KPj4gWW91J3ZlIGJlZW4gYSBnb29kIGZyaWVuZCBvdmVy IHRoZSB5ZWFycywgc28gSSdsbCBzdGF0ZSBpdCBiYWxkbHkuDQo+PiBUaGUgR1VJIG9mIE1h Y3JpdW0gUmVmbGVjdCBkaWRuJ3QgaGF2ZSB0aGUgU1lTVEVNIFJFU0VSVkVEIHBhcnRpdGlv biANCj4+IHRpY2tlZDsgYW5kIEkgZGlkbid0IG9yaWdpbmFsbHkgbm90aWNlLg0KPj4gQXMg dG8gd2h5IGl0IHdhc24ndCB0aWNrZWQsIEkgY2FuIG9ubHkgc3BlY3VsYXRlLiBNeSBiZXN0 IGd1ZXNzIGlzIA0KPj4gc29tZSBzbGlwIG9mIG15IGhhbmQuDQo+PiBOb3cgdGhhdCBJJ3Zl IHRpY2tlZCBpdCwgdGhlIEdVSSBhbHdheXMgcHJlc2VudHMgd2l0aCBpdCBhbHJlYWR5IHRp Y2tlZC4NCj4+DQo+PiBFZA0KPj4NCj4+DQo+IFRoZSBwcmUtc2VsZWN0aW9uIG9mIHBhcnRp dGlvbnMgaW4gTWFjcml1bSBieSBkZWZhdWx0IGRlcGVuZHMgdXBvbiB0aGUgDQo+IG9wdGlv biBjaG9zZW4uDQo+IC0gaW1hZ2Ugc2VsZWN0ZWQgZGlza3MNCj4gLSBpbWFnZSB0aGUgcGFy dGl0aW9ucyByZXF1aXJlZCB0byBiYWNrdXAgYW5kIHJlc3RvcmUgV2luZG93cw0KPiANCj4g VGhlIHRlbXBsYXRlKHhtbCkgYW5kL29yIHRoZSBiYWNrdXAgc2F2ZWQgcmVtZW1iZXJzIHdo YXQgZXZlciB3YXMgYWNjZXB0ZWQuDQo+IA0KPiBJZiBvbmUgY2hvb3NlcyB0byBzYXZlIHRo ZSBzZXR0aW5ncyhhcy1kZXNpZ25lZCBvciB1c2VyIG1vZGlmaWVkKSB0aGUgDQo+IG5leHQg dXNlIHJldGFpbnMgdGhlIGNob2ljZS4NCj4gDQo+IGkuZS4gd3lzaXd5ZyBpcyByZWFsbHkg d3lzaXd5cGQgLSAnd2hhdCB5b3Ugc2VlIGlzIHdoYXQgeW91IHByZXZpb3VzbHkgZGlkJw0K PiANCg0KTmljZSB3b3JkLXBsYXkgd2l0aCBhY3Jvbnltcy4NCkp1c3QgYXMgV2luZG93cyBF eHBsb3JlciByZW1lbWJlcnMgZGV0YWlscyBvZiBlYWNoIGluZGl2aWR1YWwgZGlzcGxheS4N Ckkgc3VwcG9zZSB0aGF0IHdvcmtzIGJ5IHNpbXBseSBzYXZpbmcgdGhlIGNvLW9yZGluYXRl cyB0byBzb21lIGZpbGUuIEFuZCANCldFeHBsIGlzIHRpZWQgd2l0aCBhbiB1bWJpbGljYWwg Y29yZCB0byB0aG9zZSBmaWxlcy4NCg0KVGhlcmUncyBhbm90aGVyIGhldXJpc3RpYyBlbGVt ZW50IGF0IHBsYXkgaW4gV2luMTA7IG9uZSB0aGF0J3MgbGlua2VkIHRvIA0Kc2VhcmNoZXMg aW4gdGhlIHRhc2tiYXIuIEkgb25seSBoYXZlIHRvIHR5cGUgIlMiIHVzdWFsbHkgYW5kIHVw IGNvbWVzIA0KU3B5Ym90LiBCdXQgdGhpcyBjaGFuZ2VzOyBzb21ldGltZXMgaXQncyBTbmlw cGluZyBUb29sLCBzb21ldGltZXMgDQpTZXJ2aWNlcywgc29tZXRpbWVzIFNodXRkb3duIFBD Lg0KDQpMaWtlIHlvdSwgSSBmaW5kIHRoaXMgaW50ZXJlc3RpbmcuIEl0IHNlZW1zIHRvIHBh cmFsbGVsIGFuIGV4cGxvcmF0aW9uIA0KaW50byBodW1hbiB1bmRlcnN0YW5kaW5nOyBob3cg cmVhc29uIGFuZCBpdHMgY2F0ZWdvcmllcyBhY3R1YWxseSANCmZ1bmN0aW9uIGluIHRoZSBu ZXVyb25zIGFuZCBkZW5kcml0ZXMgb2YgdGhlIGJyYWluLg0KV2VpZ2h0LWxvYWRpbmdzIGFj cm9zcyBzeW5hcHRpYyBnYXBzOyBhbmQgb25lIGV4cGVyaWVuY2VzIHdoYXQgb25lIA0KZXhw ZXJpZW5jZXMgaW4gdGhlIGJleW9uZC1zY2llbmNlIGh1bWFuIG1pbmQuDQoNCkVkDQoNCg0K
DQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

RWQgQ3J5ZXIgd3JvdGU6DQo+IC4uLnfCocOxwqfCscKkw7Egd3JvdGU6DQo+PiBFZCBDcnll ciB3cm90ZSBvbiAxMi80LzI0IDM6MjMgQU06DQo+Pj4gUGF1bCB3cm90ZToNCj4+Pj4gT24g VHVlLCAxMi8zLzIwMjQgMjoyOCBQTSwgRWQgQ3J5ZXIgd3JvdGU6DQo+Pj4+PiBFZCBDcnll ciB3cm90ZToNCj4+Pj4+PiBJIHByb2R1Y2VkIGFuIGltYWdlIG9mIG15IEMgZGlzayB0b2Rh eSwgYW5kIGdvdCBhbiBpbml0aWFsIG1lc3NhZ2UgDQo+Pj4+Pj4gdGhhdCBJJ3ZlIG5vdCBz ZWVuIGJlZm9yZTsgYSB3YXJuaW5nIHRoYXQgcGFydHMgb2YgdGhlIG9wZXJhdGluZyANCj4+ Pj4+PiBzeXN0ZW0gd291bGRuJ3QgYmUgc2F2ZWQuDQo+Pj4+Pj4gSG93IGxvbmcgaGFzIHRo aXMgYmVlbiBnb2luZyBvbj8NCj4+Pj4+Pg0KPj4+Pj4+IEVkDQo+Pj4+Pg0KPj4+Pj4gVGhl IEMgZHJpdmUgaGFzIDMgcGFydGl0aW9ucw0KPj4+Pj4gUFFTRVJWSUNFDQo+Pj4+PiBTWVNU RU0gUkVTRVJWRUQNCj4+Pj4+IFdpbi0xMA0KPj4+Pj4NCj4+Pj4+IEFsbCBwcmV2aW91cyBN YWNyaXVtIGltYWdlcyBjb250YWluIGFsbCB0aHJlZS4gVGhlIGxhdGVzdCBjb250YWlucyAN Cj4+Pj4+IG9ubHkgdHdvLCB0aGUgU1lTVEVNIFJFU0VSVkVEICgxMDBNQikgaXNuJ3Qgc2F2 ZWQuDQo+Pj4+PiBUaGF0IHBhcnRpdGlvbiBjb250YWlucyBib290IGluZm9ybWF0aW9uIGlu IGZpbGVzIGRhdGVkIG9uIHRoZSBkYXkgDQo+Pj4+PiB0aGUgT1Mgd2FzIGZpcnN0IGluaXRp YWxpc2VkOyBhcGFydCBmcm9tLCB0aGF0IGlzLCBhbiBlbXB0eSANCj4+Pj4+ICRSRUNZQ0xF LkJJTiBhbmQgYW4gZW1wdHkgU3lzdGVtIFZvbHVtZSBJbmZvcm1hdGlvbiBmb2xkZXIuDQo+ Pj4+Pg0KPj4+Pj4gVGhlcmVmb3JlLCBJIGNhbiBkbyBhIGZ1bGwgc3lzdGVtIHJlc3RvcmUg ZnJvbSB0aGUgbGF0ZXN0IGltYWdlIA0KPj4+Pj4gd2l0aG91dCBhbnkgbG9zcyBvciBjb3Jy dXB0aW9uLg0KPj4+Pj4NCj4+Pj4+IFRoZSBxdWVzdGlvbiByZW1haW5zOyB3aGVuIGRpZCB0 aGlzIGNoYW5nZSBpbiBNYWNyaXVtIFJlZmxlY3QgY29tZSANCj4+Pj4+IGluPyBXaGF0IGNh dXNlZCBpdD8gU29tZSBjaGFuZ2UgaW4gbXkgc3lzdGVtIG9yIGFuIHVwZGF0ZSB0byB0aGUg DQo+Pj4+PiBwcm9ncmFtPyBJIHN1c3BlY3QgdGhlIGxhdHRlciwgYW5kIHdhaXQgZm9yIG90 aGVycyB0byByZXBvcnQgdGhlIA0KPj4+Pj4gbWVzc2FnZSBhcHBlYXJpbmcgb24gdGhlaXIg c3lzdGVtcy4NCj4+Pj4+DQo+Pj4+DQo+Pj4+IFRoYXQgcGF0dGVybiBpcyBhIFcxMC1vdmVy LVc3IGluc3RhbGxhdGlvbi4NCj4+Pj4NCj4+Pj4gVGhlIFBRU0VSVklDRSBtaWdodCBiZSAx NUdCIG9yIHNvLCBhbmQgY29udGFpbiBXaW5kb3dzIDcgRmFjdG9yeS4NCj4+Pj4NCj4+Pj4g SSBoYXZlIGEgY2xlYW4gV2luMTAgaW5zdGFsbCBvbiBNU0RPUyBwYXJ0aXRpb25pbmcsIGFu ZCBpdCBsb29rcyANCj4+Pj4gbGlrZSB0aGlzLg0KPj4+PiBhbmQgSSBrbm93IHRoYXQgSSBj YW4ndCBxdWl0ZSByZXByb2R1Y2UgeW91ciBzZXR1cC4gTWF5YmUgbXkgbGFwdG9wDQo+Pj4+ IHdvdWxkIGNvbWUgdGhlIGNsb3Nlc3QsIGJ1dCBJIGNhbid0IHJlbWVtYmVyIGZvciBzdXJl IHdoZXRoZXIgdGhhdA0KPj4+PiB3YXMgYSBDbGVhbiwgb3IgVzEwLW92ZXItVzcgaW5zdGFs bC4NCj4+Pj4NCj4+Pj4gwqDCoMKgIFtQaWN0dXJlXQ0KPj4+Pg0KPj4+PiBodHRwczovL2ku cG9zdGltZy5jYy9IV3FNUEJ4Wi9XMTAtTVNET1MtUGFydGl0aW9uLVdBRkZMRVMtIA0KPj4+ PiBTYW1zdW5nLTI1Ni5naWYNCj4+Pj4NCj4+Pj4gT0ssIHRoaXMgb25lIGlzIGEgYml0IGNs b3NlciB0byBhIFcxMC1vdmVyLVc3IHdpdGggTVNET1MgDQo+Pj4+IHBhcnRpdGlvbmluZyAo TEFQVE9QKS4NCj4+Pj4gVGhlIFN5c3RlbSBSZXNlcnZlZCBpcyBvbiB0aGUgcmlnaHQgc2lk ZSBvZiBDOiBhbmQgdGhlIHVwZ3JhZGUgcHJvY2Vzcw0KPj4+PiAob2YgY3JlYXRpbmcgYWRk aXRpb25hbCBTeXN0ZW0gUmVzZXJ2ZWQgYW5kIG5vdCBjbGVhbmluZyB1cCB0aGUgDQo+Pj4+ IGRlY29tbWlzc2lvbmVkDQo+Pj4+IFN5c3RlbSBSZXNlcnZlZCksIGlzIG5vdCBwb3NzaWJs ZSBmb3IgdGhlIFdpbmRvd3MgVXBkYXRlIGxvZ2ljIHRvIA0KPj4+PiBoYW5kbGUuDQo+Pj4+ IFRoZSBTeXN0ZW0gUmVzZXJ2ZWQgd2FzIG1hZGUgbGFyZ2VyIGZvciB0aGUgV2luUkUgbGFy Z2VyIHNpemUgaXNzdWUuDQo+Pj4+IFNpbmNlIHRoZXJlIGFyZSBvbmx5IGZvdXIgcHJpbWFy eSBwYXJ0aXRpb25zIG9uIE1TRE9TIGFuZCAoc25pY2tlcikgDQo+Pj4+IEkgdXNlZA0KPj4+ PiB0aGVtIGFsbCB1cCwgV2luZG93cyBpcyBwcmV2ZW50ZWQgZnJvbSBtYWtpbmcgYSBtZXNz Lg0KPj4+Pg0KPj4+PiDCoMKgwqAgW1BpY3R1cmVdDQo+Pj4+DQo+Pj4+IMKgwqDCoCBodHRw czovL2kucG9zdGltZy5jYy9GUm5xMDFqNi9MQVBUT1AtcGFydGl0aW9uLXRhYmxlLU1TRE9T LmdpZg0KPj4+Pg0KPj4+PiBXaGlsZSB0aGF0IGlzIGNsb3NlciB0byB5b3VycywgaXQncyBu b3QgYSBwZXJmZWN0IG1hdGNoIGJ5IGFueSBzdHJldGNoLg0KPj4+PiBJdCdzIGp1c3QgaW4g dGhlIHNhbWUgYmFsbHBhcmsuIEkgZGlkbid0IHRha2UgYSBQUUVESVQzMiBwaWN0dXJlLA0K Pj4+PiBhcyB0aGUgYm9vdCBmbGFnIHdpbGwgYmUgd2hlcmUgdGhlICJib290IiBsYWJlbCBp cyByZWNvcmRlZCBpbiB0aGUgDQo+Pj4+IHNlY29uZCBwaWN0dXJlLg0KPj4+Pg0KPj4+PiAq KioqKioqDQo+Pj4+DQo+Pj4+IEFueSB0aW1lIGEgcGFydGl0aW9uIHNpemUgaXMgZGlzdHVy YmVkLCB5b3Ugc2hvdWxkIG1ha2UgYSBuZXcgQmFja3VwIA0KPj4+PiBzZXR0aW5ncw0KPj4+ PiBmaWxlIG9yIGVkaXQgdGhlIGV4aXN0aW5nIG9uZS4gVGhhdCdzIG9uZSBvZiB0aGUgcHJv YmxlbXMgb2YgbGl2aW5nIA0KPj4+PiBpbiBhDQo+Pj4+IGR5bmFtaWMgZW52aXJvbm1lbnQs IHdoZXJlIHlvdSBkb24ndCBjb250cm9sIGV2ZXJ5dGhpbmcuIFlvdSBoYXZlIHRvIA0KPj4+ PiBub3RpY2UNCj4+Pj4gd2hlbiBzb21ldGhpbmcgaXMgYnJva2VuLCB0aGVuIGNvbnNpZGVy IGhvdyBtYW55IGJhY2t1cCBpbWFnZXMNCj4+Pj4gaGF2ZSBiZWVuIGJyb2tlbiBieSB0aGUg Y2hhbmdlIChsaWtlIGluIHRoZSBtaWRkbGUgb2YgYSANCj4+Pj4gRnVsbCtJbmNyZW1lbnRh bHMgc2V0KSwgdGhlbiBkbw0KPj4+PiB3aGF0ZXZlciBpcyBuZWNlc3NhcnkgdG8ga2ljayBv ZmYgYSBuZXcgc2V0IG9mIGJhY2t1cHMsIHdpdGgNCj4+Pj4gYW1lbmRlZCBwYXJ0aXRpb24g aW5mby4gV2hhdGV2ZXIgaXQgaGFwcGVucyB0byB3YW50Lg0KPj4+Pg0KPj4+PiBDb21wbGV0 ZSBzZXRzIG9mIG9sZCBiYWNrdXBzIGFyZSBub3QgYnJva2VuIGFzIHN1Y2guIElmIHlvdSBo YWQNCj4+Pj4gdG8gcmVzdG9yZSB0byBhIGJyYW5kIG5ldyBoYXJkIGRyaXZlLCB0aGUgdGhp bmcgd291bGQgYm9vdCBhbmQgc28gb24uDQo+Pj4+DQo+Pj4+IEFuZCBpZiB5b3UgcmVzdG9y ZSB0byBhIHBhcnRpdGlvbiB3aGljaCBpcyBzbWFsbGVyLCBNYWNyaXVtIGRvZXMgbm90DQo+ Pj4+IG1pbmQsIHVubGVzcyB0aGUgdG90YWwgZmlsZXMgd29uJ3QgZml0IGluIHRoZSBwYXJ0 aXRpb24gOi0pIE1hY3JpdW0NCj4+Pj4gc3VwcG9ydCByZXNpemUtb24tcmVzdG9yZSwgYSBo YW5keSBmZWF0dXJlLg0KPj4+Pg0KPj4+PiBTaG91bGQgeW91IHRlc3QgdGhlIGFiaWxpdHkg dG8gYm9vdCBhIHJlc3RvcmF0aW9uID8NCj4+Pj4NCj4+Pj4gWWVzLg0KPj4+Pg0KPj4+PiBB bmQgdGhlICJzcGFyZSBkcml2ZSIgeW91IHB1cmNoYXNlIGZvciB0aGlzIHRlc3QgY2FzZSwN Cj4+Pj4gb2YgcmVzdG9yaW5nIHRvIGEgbmV3IGRyaXZlLCB0aGF0ICJzcGFyZSBkcml2ZSIg ZnVuY3Rpb25zDQo+Pj4+IGFzIHlvdXIgInJlcGxhY2VtZW50IGRyaXZlIiB3aGVuIHRoZSBv dGhlciBvbmUgd2VhcnMgb3V0Lg0KPj4+PiBJdCdzIG5vdCB3YXN0ZWQgbW9uZXksIHRoZSBz cGFyZSBkcml2ZSB3aWxsIGNvbWUgaW4gaGFuZHkNCj4+Pj4gd2hlbiB0aGUgdGltZSBjb21l cy4gSWYgeW91IHNlbGwgdGhlIGNvbXB1dGVyLCB5b3UgY2FuIHNlbGwNCj4+Pj4gdGhlIHNw YXJlIHdpdGggaXQsIGF0IHJlY292ZXJ5IGNvc3QgcHJpY2UuDQo+Pj4+DQo+Pj4+ICoqKioq KioNCj4+Pj4NCj4+Pj4gSWYgeW91IHN0aWxsIGhhdmUgYSBjb3B5IG9mICJJbWdUb1ZIRC5l eGUiIHRoYXQgTWFjcml1bSB1c2VkIHRvIGhhdmUsDQo+Pj4+IHRoYXQgY2FuIGNvbnZlcnQg YSAic21hbGwiIE1SSU1HIChhIGZ1bGwgYmFja3VwKSB0byBhIFZIRCBmaWxlLg0KPj4+PiBU aGUgVkhEIGZpbGUgY2FuIGJlIG1vdW50ZWQgaW4gV2luZG93cyBpbiBEaXNrIE1hbmFnZW1l bnQsIGFuZA0KPj4+PiB0aGVuIHlvdSBjYW4gdXNlIG9yZGluYXJ5IHRvb2xzIGZvciBtZWFz dXJpbmcgdGhlIHNpemUgb2YgcGFydGl0aW9ucw0KPj4+PiBhbmQgc28gb24uIEFuIE1SSU1H IGNhbiBhbHNvIGJlIG1vdW50ZWQgaW4gV2luZG93cywgZm9yIGZvcmVuc2ljDQo+Pj4+IHB1 cnBvc2VzLCB1c2luZyB0aGUgTWFjcml1bSBvcHRpb24gdG8gbW91bnQgYW4gaW1hZ2UuIFRo ZXJlIHNob3VsZA0KPj4+PiBnZW5lcmFsbHkgYmUgd2F5cyBvZiBnYWluaW5nIGZvcmVuc2lj IGFuYWx5c2lzIGNhcGFiaWxpdHksIHRvDQo+Pj4+IGNvbXBhcmUgdGhlIG9sZGVyIHNldHMg b2YgYmFja3VwcywgdG8gYW55IG5ld2VyIHNldHMsIGlmIHRoZSBuZWVkIA0KPj4+PiBhcmlz ZXMuDQo+Pj4+DQo+Pj4+IMKgwqDCoCBQYXVsDQo+Pj4NCj4+PiBIaSwgUGF1bA0KPj4+DQo+ Pj4gSSBoYXZlIHRoZSBmdWxsIHNvbHV0aW9uIG5vdywgYW5kIGl0J3Mgc28gc2ltcGxlIHRo YXQgSSBmZWVsIGFsbW9zdCANCj4+PiBhc2hhbWVkIG9mIG15c2VsZiBmb3Igbm90IGhhdmlu ZyBzb2x2ZWQgaXQgZWFybGllciB3aXRob3V0IGhhdmluZyB0byANCj4+PiBwb3N0IGhlcmUu DQo+Pj4gWW91J3ZlIGJlZW4gYSBnb29kIGZyaWVuZCBvdmVyIHRoZSB5ZWFycywgc28gSSds bCBzdGF0ZSBpdCBiYWxkbHkuDQo+Pj4gVGhlIEdVSSBvZiBNYWNyaXVtIFJlZmxlY3QgZGlk bid0IGhhdmUgdGhlIFNZU1RFTSBSRVNFUlZFRCBwYXJ0aXRpb24gDQo+Pj4gdGlja2VkOyBh bmQgSSBkaWRuJ3Qgb3JpZ2luYWxseSBub3RpY2UuDQo+Pj4gQXMgdG8gd2h5IGl0IHdhc24n dCB0aWNrZWQsIEkgY2FuIG9ubHkgc3BlY3VsYXRlLiBNeSBiZXN0IGd1ZXNzIGlzIA0KPj4+ IHNvbWUgc2xpcCBvZiBteSBoYW5kLg0KPj4+IE5vdyB0aGF0IEkndmUgdGlja2VkIGl0LCB0 aGUgR1VJIGFsd2F5cyBwcmVzZW50cyB3aXRoIGl0IGFscmVhZHkgdGlja2VkLg0KPj4+DQo+ Pj4gRWQNCj4+Pg0KPj4+DQo+PiBUaGUgcHJlLXNlbGVjdGlvbiBvZiBwYXJ0aXRpb25zIGlu IE1hY3JpdW0gYnkgZGVmYXVsdCBkZXBlbmRzIHVwb24gdGhlIA0KPj4gb3B0aW9uIGNob3Nl bi4NCj4+IC0gaW1hZ2Ugc2VsZWN0ZWQgZGlza3MNCj4+IC0gaW1hZ2UgdGhlIHBhcnRpdGlv bnMgcmVxdWlyZWQgdG8gYmFja3VwIGFuZCByZXN0b3JlIFdpbmRvd3MNCj4+DQo+PiBUaGUg dGVtcGxhdGUoeG1sKSBhbmQvb3IgdGhlIGJhY2t1cCBzYXZlZCByZW1lbWJlcnMgd2hhdCBl dmVyIHdhcyANCj4+IGFjY2VwdGVkLg0KPj4NCj4+IElmIG9uZSBjaG9vc2VzIHRvIHNhdmUg dGhlIHNldHRpbmdzKGFzLWRlc2lnbmVkIG9yIHVzZXIgbW9kaWZpZWQpIHRoZSANCj4+IG5l eHQgdXNlIHJldGFpbnMgdGhlIGNob2ljZS4NCj4+DQo+PiBpLmUuIHd5c2l3eWcgaXMgcmVh bGx5IHd5c2l3eXBkIC0gJ3doYXQgeW91IHNlZSBpcyB3aGF0IHlvdSBwcmV2aW91c2x5IA0K Pj4gZGlkJw0KPj4NCj4gDQo+IE5pY2Ugd29yZC1wbGF5IHdpdGggYWNyb255bXMuDQo+IEp1 c3QgYXMgV2luZG93cyBFeHBsb3JlciByZW1lbWJlcnMgZGV0YWlscyBvZiBlYWNoIGluZGl2 aWR1YWwgZGlzcGxheS4NCj4gSSBzdXBwb3NlIHRoYXQgd29ya3MgYnkgc2ltcGx5IHNhdmlu ZyB0aGUgY28tb3JkaW5hdGVzIHRvIHNvbWUgZmlsZS4gQW5kIA0KPiBXRXhwbCBpcyB0aWVk IHdpdGggYW4gdW1iaWxpY2FsIGNvcmQgdG8gdGhvc2UgZmlsZXMuDQo+IA0KPiBUaGVyZSdz IGFub3RoZXIgaGV1cmlzdGljIGVsZW1lbnQgYXQgcGxheSBpbiBXaW4xMDsgb25lIHRoYXQn cyBsaW5rZWQgdG8gDQo+IHNlYXJjaGVzIGluIHRoZSB0YXNrYmFyLiBJIG9ubHkgaGF2ZSB0 byB0eXBlICJTIiB1c3VhbGx5IGFuZCB1cCBjb21lcyANCj4gU3B5Ym90LiBCdXQgdGhpcyBj aGFuZ2VzOyBzb21ldGltZXMgaXQncyBTbmlwcGluZyBUb29sLCBzb21ldGltZXMgDQo+IFNl cnZpY2VzLCBzb21ldGltZXMgU2h1dGRvd24gUEMuDQo+IA0KPiBMaWtlIHlvdSwgSSBmaW5k IHRoaXMgaW50ZXJlc3RpbmcuIEl0IHNlZW1zIHRvIHBhcmFsbGVsIGFuIGV4cGxvcmF0aW9u IA0KPiBpbnRvIGh1bWFuIHVuZGVyc3RhbmRpbmc7IGhvdyByZWFzb24gYW5kIGl0cyBjYXRl Z29yaWVzIGFjdHVhbGx5IA0KPiBmdW5jdGlvbiBpbiB0aGUgbmV1cm9ucyBhbmQgZGVuZHJp dGVzIG9mIHRoZSBicmFpbi4NCj4gV2VpZ2h0LWxvYWRpbmdzIGFjcm9zcyBzeW5hcHRpYyBn YXBzOyBhbmQgb25lIGV4cGVyaWVuY2VzIHdoYXQgb25lIA0KPiBleHBlcmllbmNlcyBpbiB0 aGUgYmV5b25kLXNjaWVuY2UgaHVtYW4gbWluZC4NCj4gDQo+IEVkDQo+IA0KPiANCj4gDQpU aGVzZSBzcGVjdWxhdGlvbnMgZm9ybSB0aGUgY29yZSBvZiB0aGUgZ3JlYXQgYWdlIG9mIHBo aWxvc29waGljYWwgYW5kIA0Kc2NpZW50aWZpYyByZWFzb25pbmcuIEpvaG4gTG9ja2UsIEdl b3JnZSBCZXJrZWxleSwgRGF2aWQgSHVtZSwgSW1tYW51ZWwgDQpLYW50Lg0KVGhleSB3ZXJl IHN0cnVnZ2xpbmcgdG8gcmVjb25jaWxlIHR3byBkaWZmZXJlbnQgZ3JvdXBzIG9mIGtub3ds ZWRnZTsgDQpzY2llbnRpZmljIHVuZGVyc3RhbmRpbmcgd2l0aCBodW1hbiBleHBlcmllbmNl LiBIb3cgZG9lcyB0aGUgbWluZCB3b3JrPyANCldoYXQgZnJvbSB0aGUgbmF0dXJhbCB3b3Js ZCBjcmVhdGVkIGl0IGFuZCBmZWVkcyBpdD8gSG93IGRvZXMgcGVyY2VwdGlvbiANCmdldCBm aWx0ZXJlZCBhbmQgZ2VuZXJhdGUgdGhpbmdzIGxpa2UgY29sb3VyIGFuZCBzb3VuZD8gSG93 IGRvIHRoZSANCmVtb3Rpb25zIG9mIGZlYXIgYW5kIGxvdmUgYW5kIGhhdHJlZCBmdW5jdGlv biBhbWlkc3QgYWxsIHRoYXQ/DQoNCkkgdGhpbmsgdGhleSB3ZXJlIGNvbnZpbmNlZCB0aGF0 IHRoZSBtaW5kIGlzIHB1cmVseSBtZWNoYW5pY2FsOyB0aGF0IHRoZSANCmJyYWluIHByb2R1 Y2VzIGl0LiBCdXQganVzdCBob3c/DQoNCkluIHRvZGF5J3MgYWNhZGVtaWMgd29ybGQgd2Ug aGF2ZSB0aGUgc3Bpbi1vZmZzIG9mIGFsbCB0aGF0OyBtaW5kIA0KdGhlb3JpZXMuIEZ1bmN0 aW9uYWxpdHksIGlkZW50aXR5IHRoZW9yeSwgR29kIGFuZCBoaXMgd29uZGVycywNCkl0IGFw cGVhcnMgdG8gYmUgYmV5b25kIHNjaWVuY2U7IGNlcnRhaW5seSBiZXlvbmQgdGhlIHByb2Jp bmcgb2YgDQppbnRlbGxlY3Q7IHJhdGhlciBsaWtlIGdyYXZpdHkgb3IgcXVhbnR1bSB0aGVv cnk7IGp1c3Qgc29tZSBnaXZlbiBvZiB0aGUgDQp1bml2ZXJzZSwgdGhhdCB5b3UgY2FuIG9u bHkgY2FsbCAiYW4gZW1lcmdlbnQgcHJvcGVydHkiLg0KUHVyZSBlbmVyZ3ksIGNvbmRlbnNl ZCBpbnRvIGFuIGluZmluaXRlc2ltYWxseSB0aW55IGJhbGwsIGZyb20gd2hpY2ggYWxsIA0K YXRvbXMgYW5kIHRoZWlyIHBhcnRpY2xlcyBzcHJhbmc7IGFuZCBmaW5hbGx5IHByb2R1Y2Vk IG91ciBicmFpbnMgZnJvbSANCnRoZSBjYXJib24gZ2l2ZW4gb2ZmIGZyb20gY29sbGFwc2lu ZyBzdGFycy4NCg0KSXQncyBubyB3b25kZXIgdGhhdCBhbWlkc3QgYWxsIHRoYXQgbXlzdGVy eSBhYm91dCBvdXIgbWluZHMsIHBlb3BsZSBydW4gDQpwYXJhbm9pZCBhYm91dCB0aGUgcmlz ZSBvZiBBSSBhbmQgaG93IGl0cyBvd24gZnV0dXJlIHdlbGxiZWluZyB3aWxsIA0KYnJpbmcg aXQgaW50byBjb2xsaXNpb24gd2l0aCBvcmdhbmljIG1pbmRzOyBhbmQgdGhlbiB0aGV5J2xs IHRyeSBhbmQgDQp3aXBlIHVzIG91dC4NCllvdSBtaWdodCBqdXN0IGFzIHdlbGwgdGVsbCB1 cyBhYm91dCBob3cgR29kIHdpcGVkIG91dCB0aGlzIG9yIHRoYXQgDQpjaXR5LCB0aGlzIG9y IHRoYXQgd29ybGQuIE15c3RpY2lzbSwgc3BlY3VsYXRpb24gYW5kIGZvZGRlciBmb3IgY29v a3Mgb24gDQpzb2FwYm94ZXMgYXQgSHlkZSBQYXJrIENvcm5lci4NCg0KDQpFZA0KDQoNCg0K
DQo=

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 12/4/2024 4:35 PM, Ed Cryer wrote:

It's no wonder that amidst all that mystery about our minds, people
run paranoid about the rise of AI and how its own future wellbeing will
bring it into collision with organic minds; and then they'll try and wipe us out.
You might just as well tell us about how God wiped out this or that city, this or that world. Mysticism, speculation and fodder for cooks on
soapboxes at Hyde Park Corner.

Their current state is "the first transistor".

It's going to be a while, before they're a topic of discussion.

Like fusion, only fifty years to go.

I gave one a query, and like a computer program, it hung
in the I/O state and ignored the 15 second safety timer
and kept running. And from that, I learned exactly
what we have to fear.

If you ask it to write a computer program, it does do
that. It writes a computer program. But it is pretty difficult
to figure out exactly what environment it would run in. The AI
does not simulate execution, compile and link, debug,
it does none of those things currently.

And the AI does not have this in its vocabulary.

"I don't know"

Won't it have to emit that, at some point ? Maybe as a joke.
That would be a measure of its self-awareness.

It has the possibility of voluminous output. Bad images. Bad movies.
The advertisers love it. I like humans with six fingers to
display my wares, as an advertiser.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)