From: Paul <nospam@needed.invalid>
Subject: Re: A simple way to transfer photos from your phone to Windows withoutinstalling anything on either
Full headers:
From: Paul <nospam@needed.invalid>
Subject: Re: A simple way to transfer photos from your phone to Windows without
installing anything on either
Date: Sat, 24 Feb 2018 21:58:46 -0500
Organization: A noiseless patient Spider
Lines: 122
Message-ID: <p6t8p7$ckt$>
References: <1pat6bvdosd5h$.1v0zueckye1z0$> <N8CjC.87760$CZ2.56323@fx39.iad> <k1708hh1x1bm.4u71bsj0gbj3$> <p6n7mu$cuh$> <19gis5r2t3woe$.15ka8hlpcnip0$> <9K3kC.89577$CZ2.67163@fx39.iad> <1dxxhzinci9qd.hpx5dw75usol$> <p6r6ge$5f4$> <acakC.112774$mJ1.26756@fx13.fr7> <p6s785$nht$> <v9lfsboe3dmc.1o44r2zk1zgx8$>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 25 Feb 2018 02:58:47 -0000 (UTC)
Injection-Info:; posting-host="4f4141287054980788e145d1336d08ee";
logging-data="12957"; mail-complaints-to="";posting-account="U2FsdGVkX18l815MUaxSzBtIPJTI76P2eyytpUVPF9U="
User-Agent: Ratcatcher/ (Windows/20130802)
In-Reply-To: <v9lfsboe3dmc.1o44r2zk1zgx8$>
Cancel-Lock: sha1:r3DJNsc+Q1+Ph7SwRxMBOtf7yH0=
Print Article
Forward Article
ultred ragnusen wrote:
> Paul<nospam@needed.invalid> 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.
> 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.
> 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.
> 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.

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

    What utility is this ?  "Finished" box.

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.