ultred ragnusen wrote:
Paul wrote:

Once I burn the ISO to a disk will it be 'bootable' or will additional
action be required first?
It requires dancing a jig on one foot.

The Tier 2 Microsoft support person at +1-800-642-7676 took control of
another Windows 10 Pro system to download, burn, test, and run the same
sequence of repair that we ran (and failed at) using the bricked Windows 10
Pro recovery console.
http://wetakepic.com/images/2018/02/...dvd_repair.jpg

For the data, Knoppix worked just fine, but I am getting a very common
error from Knoppix on files that shouldn't have that error, where, when I
google for the error, NONE of the common causes can possibly be why I'm
getting that error.
Error splicing file: Value too large for defined data type.
http://wetakepic.com/images/2018/02/...x_error_01.jpg

The odd thing is that /all/ the root causes of that common error on the net
don't apply here, because the Knoppix boot alone exhibits the problem when
I copy the file to /tmp staying completely within the Knoppix file system
for the destination file.
http://wetakepic.com/images/2018/02/...x_error_02.jpg

On the net, the common reasons for that common error don't apply:
- It doesn't seem to be an NTFS issue since all the HDDs are NTFS
- It has nothing to do with the 4GB limit on file size

When Windows is installed on more than a 100 million machines, would
distributing a broken image work ? How many people would ever
figure it out ?

The second tier Microsoft support tech told me it's pretty common, saying
the reasons are many.
1. It could be a driver conflict
2. It could be a setup conflict
3. It could be a CPU conflict (the AMD CPUs were harder hit than Intel)
4. It could be a corrupted HDD (which is always a possibility)
5. It could be that I customized something that Microsoft didn't like
etc.

The Microsoft Genius Bar personnel (or whatever they're called) should be
able to allow me to tell you more when I go to my appointment.

If 100 million people phone the Microsoft support line with
"help me convert the ISO I downloaded into something useful",
how many Tier 0 employees do you think that's going to take
to help them out ? The telephone switch board will be absolutely jammed
for months and months.

I have to admit they spent at least an hour downloading, installing, and
activating Microsoft Office 2007 Pro yesterday, and a different tech spent
at least three hours trying to repair my bricked system. They will likely
spend a few more hours at the Microsoft Genius Bar (or whatever it's
called), where they'll have access to all the information in the support
ticket that has been filed to determine what the bug is due to.

I'll let you know more when I know more, but the net is that Knoppix was
the first data-recovery system I've tried, as per your suggestion to back
up the data BEFORE going to the Microsoft Genius Bar (or whatever it's
called). I'll try the other methods, where I'm confident that the data will
be recovered since there's nothing wrong with the hard disk drive as far as
I can tell.

http://wetakepic.com/images/2018/02/24/boot_device.jpg

I had another think about this, and the first question I've
got is

What utility is this ? "Finished" box.

http://wetakepic.com/images/2018/02/...x_error_01.jpg

I tried to match that dialog with some searches but was not
successful. Since Google has ruined some of their search tools
in the name of the Getty legal challenge, I can't even enter a
snip of the orange triangle and try to get a match on that.

I see a dialog box with the word "Finished" but I can't tell what
utility put that dialog box there.

I'm beginning to think you're running a scavenger, one that scans
through the disk for recognizable file headers and tries to
reconstruct files. Such tools, will produce a hundred thousand
useless unnamed fragments of files, if given a chance.
(I know, because I tried going through a folder of such
fragments once, and it was a total waste of time.)

So maybe before I jump to conclusions inappropriate for the
situation, I need some context, like what utility did that.

I don't think the "splicing" error is that bogus error based
on fstat or fstat64, and instead, it's a utility that does
actual splicing. Such utilities locate clusters of fragmented
files, they somehow conclude the disparate clusters belong
together and slap them together.

When you use "undelete" utilities (i.e. what you shouldn't
be using in this case), those take advantage of the fact the
slot for a file, only has one byte flipped indicating the
file is deleted. This leaves lots of information for reconstruction.
Including info about what clusters are used for the file. If the
(old, deleted) file does not "collide" with any new usage of the
disk resources, the undelete utility gives a "good" status for the
file, meaning "if I recover it for you, the file will be complete".
And that status is possible, because of the nature of the situation.

However, if the $MFT is lost, scanning through a fragmented disk
trying to do stuff based purely on file headers, is doomed from the
start. And that's a kind of scavenger behavior (i.e. not an undelete
utility). Can it take advantage of the $MFT ? It could certainly try.
That's if it can find the $MFT.

So maybe by context, it can tell there are too many clusters, or
the file it's reconstructing no longer makes sense (the series
of 4CC codes doesn't look right). Maybe a file type has a length
parameter, and the length parameter doesn't match the number
of clusters being spliced to rebuild the file.

Paul