Data Recovery from lost NTFS. Help!

[Gregg OBanion]

Thanks, I will take a look at Partition Table Doctor.

 

[Gregg OBanion]

I suppose the drive is properly detected as Big ATA?

Yes. On System boot the Start Up Screen shows the Ultra 100
controller and the 4 drives as 149.05 GB.

 

[Folkert Rienstra]

Zvi. Somehow I overlooked your instructions from your 5-26 5:40 am post. (Below)
[snipped]

Post here the report file (just paste the text file into your
follow-up), and avoid top-posting!

Hello Zvi
I don't think I used ResQ correctly. Why was it trying to detect
FAT? Came home a half hour later and it was still detecting fat so I
made it finish. Here are the results. Is this what you wanted or do
I need to run the program again.

27 May 2005 21:01
Evaluation Copy *************************************** CHS mode W9x
******************* * R e s Q d i s k 576 * ********************
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing * SeeThru *
ExtBIOS * * Virus Control, Disk & Data Recovery * ON F9 *
********* *************************************** *********
* Drive * AltHelp *
********* *********
^2:FAT-16*
CHS address: Cyl 0 Head 0 Sector 1 *********
*********************** Setup Diagnostics ************************
* Disk Type: WDC WD1600JB-00HUA0 *
* BIOS/CHS IDE/LBA data *
* Number of Heads: 255 16 *

* Number of Cylinders: 1024 266305 *

Oh look, the 'Number of Cylinders' line has been corrected although there was nothing
(supposedly) wrong with it. Yet Resqdisk version is still v576. Naughty, naughty.

Now it does the BIOS/CHS correct but it does the IDE/LBA wrong.
IDE cylinders are limited to 16383, 32767 or 65,535 -depending on the number of
heads used- for drives bigger than or equal to 8GB.
The CHS of Int13/ah=48 GET DRIVE PARAMETERS is invalid for drives over 8GB.
The information flag of Int13/ah=48 will say:
cylinder/head/sectors-per-track information is valid: 'false' (cleared).

* Sectors per Track: 63 63 *
* Disk Capacity in Mbytes: 8032 131071 *
* IDE Access Time: 44 msec *
* Total sectors on drive: 268435455 *
******* Use Space to toggle between IDE and Ext.BIOS mode ********
Disk 1, Master Partition Sector, F6 for Layout



27 May 2005 21:01
Evaluation Copy *************************************** CHS mode W9x
******************* * R e s Q d i s k 576 * ********************
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing * SeeThru *
ExtBIOS * * Virus Control, Disk & Data Recovery * ON F9 *
********* *************************************** *********
* Drive * AltHelp *
********* *********
^2:FAT-16*
CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout **********************
* *
* Partition Starting Ending Reserved Total *
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors Sectors *
* 7 1 0 1 254 1023 63 63 312576642*
* 0 0 0 0 0 0 0 0 0 *
* 0 0 0 0 0 0 0 0 0 *
* 0 0 0 0 0 0 0 0 0 *
* *
******* Press Alt+B to see as boot sector, Alt+M to edit *********
Disk 1, Master Partition Sector, F6 for Layout

Mighty impressive, isn't it. Confuses the hell out of you, right?
Never mind that half of it is useless info, if not wrong.

Long way to go though.

[snip]

And lots more useless, completely wrecked quoting snipped.
[snip]
(Obviously exactly what one needs).

But works totally fine when setup properly.
OE doesn't like 'Quoted Printable posts' (refusing to quote them).
OE-Quotefix will fix that. It can sometimes fix bad quoting too.
And OE-Quotefix adds coloring as well, makes following quotes and comments
much easier.

Isn't that the one that rights it's own wrong's but leaves them for everyone else
(not using Forte) to see?

(I do) and there is a free version available.

I will look at Forte Agent then soon. Yes I think Outlook Express
does some strange things to text, breaking sentenances apart.
Yup.

Just bad formating.

You are the formatter, you are in control. Don't blame the app.

It's probably just me though.

Yup, definetely.

Thanks for the info. I will try Forte Agent.

It too has to be setup properly.

 

[Zvi Netiv]

"Zvi Netiv" <support@replace_with_domain.com> wrote in message

Hello Zvi
I don't think I used ResQ correctly. Why was it trying to detect
FAT? Came home a half hour later and it was still detecting fat so I
made it finish. Here are the results. Is this what you wanted or do
I need to run the program again.

RESQDISK ran alright and the data posted is good.

Evaluation Copy *************************************** CHS mode W9x
******************* * R e s Q d i s k 576 *
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing * SeeThru *
ExtBIOS * * Virus Control, Disk & Data Recovery * ON F9 *
********* ***************************************

From the report header I can see that although I asked to disconnect all drives
except the one under test, there was at least one additional drive still
connected!

*********************** Setup Diagnostics ************************
* Disk Type: WDC WD1600JB-00HUA0
* BIOS/CHS IDE/LBA data *
* Number of Heads: 255 16
* Number of Cylinders: 1024 266305
* Sectors per Track: 63 63
* Disk Capacity in Mbytes: 8032 131071
* IDE Access Time: 44 msec
* Total sectors on drive: 268435455
******* Use Space to toggle between IDE and Ext.BIOS mode

No problem seen here.

CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout **********************
*
* Partition Starting Ending Reserved Total
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors Sectors *
* 7 1 0 1 254 1023 63 63 312576642*
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
*
******* Press Alt+B to see as boot sector, Alt+M to edit *********
Disk 1, Master Partition Sector,

No problem here either. The partition table is OK and shows that the drive
contains a single NTFS partition of 156 GB.

Yet the important info is in what's missing here. If the drive was healthy,
then RESQDISK should have reported here the parameters of the NTFS boot sector
of the single partition. Its absence tells that the content of sector 0/1/1
(CHS notation) isn't a valid boot sector, as predicted in previous posts.

[snip]

I had to stop the data recovery from EasyRecovery Pro. It was taking
to long to write to the recovery drive/folder. (about 25 hrs was the
estimate). The files I looked at had lost all structure even file
names were changed.

Expected too, as I explained in previous posts.

Of course I only used ERP's RAW recovery tool.
GetDataBack left most file names in tact but didn't near the info
back that ERP recovered. Very little was recovered with GetDataBack.

All file recovery SW operate on the same principles and they fail all on the
same problem, i.e. lack of contiguity of the files to recover! If one such
package yields lots of broken files, then it's a waste of time and money to
pursue this avenue and try several data recovery packages on that drive.

Yet your last observation is encouraging on one aspect, i.e. the many good file
*names* suggests that the MFT is probably undamaged! But you'll have to wait to
know, until the boot sector is recovered.

Be warned that the following isn't the safest method to restore the boot sector,
but given that there is just one NTFS partition on that drive, the drive is
larger than 137 GB (which presents a problem to handling it under DOS), and the
partition table is good, then the following procedure is the simplest to fix
that boot sector. I also recommend that you adhere to the instructions, without
improvising or changing anything:

First, disconnect all drives except the one to fix.

Next, boot the computer from the XP setup CD, and press R when prompted to start
in repair mode.

From the repair console, run the command FIXBOOT and *nothing* else! This last
comment is aimed to deter those that may advise you to also run FIXMBR. Just
don't!

When done with FIXBOOT, shut down the PC, reconnect the drives, restart Windows,
and check if you can now access your files on the 160 GB drive.

Please report back here how things went.

Regards, Zvi

 

[Zvi Netiv]

Let me tell you a little story about a dog that tried to get accepted by a pack
of wolves ...

Attempting to make friends, he went sniffing the butt of his new mates, like
dogs do. When approaching to sniff one of his new mates, the partner
unexpectedly said: "look, I am a dog myself, but butt-sniffing among wolves is
considered vulgar and degrading. This is why they greet each other by rubbing
noses, instead". The newcomer said thanks for the advice, and happily went on
rubbing noses with the other wolves in the pack. Then, one day just the two
dogs met in the woods, with no wolf in sight. As the newcomer was approaching
for the nose rub greeting, the other dog said to him: "Wait! As we both know
exactly who you are, then you don't have to pretend with me, and I'll let you
sniff my butt".

[snip]

Now it does the BIOS/CHS correct but it does the IDE/LBA wrong.
IDE cylinders are limited to 16383, 32767 or 65,535 -depending on the number of
heads used- for drives bigger than or equal to 8GB.
The CHS of Int13/ah=48 GET DRIVE PARAMETERS is invalid for drives over 8GB.
The information flag of Int13/ah=48 will say:
cylinder/head/sectors-per-track information is valid: 'false' (cleared).

Clueless. You have been doing this (telling authors how they should write their
programs) to Svend, Joep and myself. Give it up, Folkert, this is way over your
league.

Besides, your trolling contributes nothing constructive to the discussion and
all it does is to mislead and confuse.

Regards, Zvi

 

[Gregg OBanion]

Hello Zvi. Your information was very encouraging. I hope It works
but before I try let me give you some more information that may be
important. I'm sorry I didn't mention it earlier.

The 4 disk array (with the malfunctioning drive) was migrated from a
Windows 2000 Pro Server machine and a Promise Ultra 133 PCI card.
Remember the array is now on WinXP SP2 with a Promise Ultra 100 PCI
card. I meant to tell you this long ago. I hope it doesn't present a
problem. I will wait to hear from you before I follow your
instructions below.

Thanks, Gregg

RESQDISK ran alright and the data posted is good.


From the report header I can see that although I asked to
disconnect all drives
except the one under test, there was at least one additional drive
still
connected!

I have now disconnected the CD Rom on Secondary IDE and ran ResQdisk
again. Here's the Report.

29 May 2005 03:31
Evaluation Copy *************************************** CHS
mode W9x
******************* * R e s Q d i s k 576 *
********************
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing *
SeeThru *
ExtBIOS * * Virus Control, Disk & Data Recovery * ON
F9 *
********* ***************************************
*********
* Drive *
AltHelp *
*********
*********
^2:FAT-16*
CHS address: Cyl 0 Head 0 Sector 1
*********
*********************** Setup Diagnostics
************************
* Disk Type: WDC WD1600JB-00HUA0
*
* BIOS/CHS IDE/LBA
data *
* Number of Heads: 255 16
*
* Number of Cylinders: 1024 266305
*
* Sectors per Track: 63 63
*
* Disk Capacity in Mbytes: 8032 131071
*
* IDE Access Time: 43 msec
*
* Total sectors on drive: 268435455
*
******* Use Space to toggle between IDE and Ext.BIOS mode
********
Disk 1, Master Partition Sector, F6 for Layout



29 May 2005 03:31
Evaluation Copy *************************************** CHS
mode W9x
******************* * R e s Q d i s k 576 *
********************
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing *
SeeThru *
ExtBIOS * * Virus Control, Disk & Data Recovery * ON
F9 *
********* ***************************************
*********
* Drive *
AltHelp *
*********
*********
^2:FAT-16*
CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout
**********************
*
*
* Partition Starting Ending Reserved Total
*
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors
Sectors *
* 7 1 0 1 254 1023 63 63
312576642*
* 0 0 0 0 0 0 0 0 0
*
* 0 0 0 0 0 0 0 0 0
*
* 0 0 0 0 0 0 0 0 0
*
*
*
******* Press Alt+B to see as boot sector, Alt+M to edit
*********
Disk 1, Master Partition Sector, F6 for Layout


The corrected report above. Old report below. Looks much the same
but I wanted to be sure you had the proper report. Sorry!

*********************** Setup Diagnostics
************************
* Disk Type: WDC WD1600JB-00HUA0
* BIOS/CHS IDE/LBA
data *
* Number of Heads: 255 16
* Number of Cylinders: 1024 266305
* Sectors per Track: 63 63
* Disk Capacity in Mbytes: 8032 131071
* IDE Access Time: 44
msec
* Total sectors on drive:
268435455
******* Use Space to toggle between IDE and Ext.BIOS mode

No problem seen here.

CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout
**********************
*
* Partition Starting Ending Reserved
Total
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors
Sectors *
* 7 1 0 1 254 1023 63 63
312576642*
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
*
******* Press Alt+B to see as boot sector, Alt+M to edit
*********
Disk 1, Master Partition Sector,

No problem here either. The partition table is OK and shows that
the drive
contains a single NTFS partition of 156 GB.

Yet the important info is in what's missing here. If the drive
was healthy,
then RESQDISK should have reported here the parameters of the NTFS
boot sector
of the single partition. Its absence tells that the content of
sector 0/1/1
(CHS notation) isn't a valid boot sector, as predicted in previous
posts.

[snip]

I had to stop the data recovery from EasyRecovery Pro. It was
taking
to long to write to the recovery drive/folder. (about 25 hrs was
the
estimate). The files I looked at had lost all structure even file
names were changed.

Expected too, as I explained in previous posts.

Of course I only used ERP's RAW recovery tool.
GetDataBack left most file names in tact but didn't near the info
back that ERP recovered. Very little was recovered with
GetDataBack.

All file recovery SW operate on the same principles and they fail
all on the
same problem, i.e. lack of contiguity of the files to recover! If
one such
package yields lots of broken files, then it's a waste of time and
money to
pursue this avenue and try several data recovery packages on that
drive.

Yet your last observation is encouraging on one aspect, i.e. the
many good file
*names* suggests that the MFT is probably undamaged! But you'll
have to wait to
know, until the boot sector is recovered.

Be warned that the following isn't the safest method to restore
the boot sector,
but given that there is just one NTFS partition on that drive, the
drive is
larger than 137 GB (which presents a problem to handling it under
DOS), and the
partition table is good, then the following procedure is the
simplest to fix
that boot sector. I also recommend that you adhere to the
instructions, without
improvising or changing anything:

First, disconnect all drives except the one to fix.

Next, boot the computer from the XP setup CD, and press R when
prompted to start
in repair mode.

From the repair console, run the command FIXBOOT and *nothing*
else! This last
comment is aimed to deter those that may advise you to also run
FIXMBR. Just
don't!

When done with FIXBOOT, shut down the PC, reconnect the drives,
restart Windows,
and check if you can now access your files on the 160 GB drive.

Please report back here how things went.

Regards, Zvi
--
NetZ Computing Ltd. ISRAEL www.invircible.com www.ivi.co.il
(Hebrew)
InVircible Virus Defense Solutions, ResQ and Data Recovery
Utilities

 

[Zvi Netiv]

Hello Zvi. Your information was very encouraging. I hope It works
but before I try let me give you some more information that may be
important. I'm sorry I didn't mention it earlier.

The 4 disk array (with the malfunctioning drive) was migrated from a
Windows 2000 Pro Server machine and a Promise Ultra 133 PCI card.
Remember the array is now on WinXP SP2 with a Promise Ultra 100 PCI
card. I meant to tell you this long ago. I hope it doesn't present a
problem. I will wait to hear from you before I follow your
instructions below.
[snip]

I have now disconnected the CD Rom on Secondary IDE and ran ResQdisk
again. Here's the Report.

ResQdisk reports INT-13 devices, from 80h and up (BIOS notation), i.e. only HARD
drives. I didn't make it clear, since I thought it was obvious.

The new report from May 29 still shows the presence of additional HARD drives
connected in that PC. You should leave the CD drive(s) connected, how else will
you boot the CD repair console?

The installed Windows version is irrelevant, as there should be no "installed"
system at the time you run FIXBOOT. You should be working with a single HARD
drive connected and boot of a W2K or XP setup CD. Either have FIXBOOT as part
of their "repair console", and you may use the one or the other.

Regards, Zvi

 

[Eric Gisin]

Clueless. You have been doing this (telling authors how they should write their
programs) to Svend, Joep and myself. Give it up, Folkert, this is way over your
league.

Besides, your trolling contributes nothing constructive to the discussion and
all it does is to mislead and confuse.

Here, here.

Folknuts, you don't have a clue. Especially on CHS in NT.

 

[Gregg OBanion]

I was away for a couple days. Sorry for the delay. I will complete
your instructions later today. Thanks Zvi.

Regards Gregg

Hello Zvi. Your information was very encouraging. I hope It works
but before I try let me give you some more information that may
be
important. I'm sorry I didn't mention it earlier.

The 4 disk array (with the malfunctioning drive) was migrated
from a
Windows 2000 Pro Server machine and a Promise Ultra 133 PCI card.
Remember the array is now on WinXP SP2 with a Promise Ultra 100
PCI
card. I meant to tell you this long ago. I hope it doesn't
present a
problem. I will wait to hear from you before I follow your
instructions below.
[snip]

I have now disconnected the CD Rom on Secondary IDE and ran
ResQdisk
again. Here's the Report

ResQdisk reports INT-13 devices, from 80h and up (BIOS notation),
i.e. only HARD drives. I didn't make it clear, since I thought it
was obvious.

How on earth do you read all that information from that little
report? I just don't see it. Amazing! If you have time would you
break it down for me so I have a clue? Where can I go to learn more
about hard drives?

The new report from May 29 still shows the presence of additional
HARD drives connected in that PC. You should leave the CD
drive(s)
connected, how else will you boot the CD repair console?

This I don't understand. There is only a floppy connected now and I
will reconnect the CD Rom as Secondary IDE, Master. Nothing Else is
connected. The network is connected still to the Router but ResQ
wouldn't detect that would it?

 

[Gregg OBanion]

Hi Zvi.

FIXBOOT Restored the drive although I'm missing most files I was
hoping to regain.

It imeadiatly ran chkdisk on system start. Chkdisk said: Deleting
orphan file record segment, up to about 60,000 + files. Then it said
verifying Indexes, then Inserting index entry, Replacing invalid
security ID, Inserting data attribute and correcting errors in boot
file. I missed some of them. I wonder if I should have stopped check
disk?

Remember the problem happened when I renamed the Drive and at the
same time I was transfering a folder containing all my JPG images.
That folder is gone.

The Drive also Retained it's Drive letter (F) and I notice that the
Drive name change took affect. It now has a new name I choose.

It's funny that the one folder I had not yet transfered from the
drive remained intact. Although the top folder in the hierarchy
seemed to be renamed, (dir0000.chk) etc...the folders inside it
retained their complete folder names as well as file names but
folders were missing within thoose folders.

Whats my next step? Data recovery software. What is the best?

Thanks Gregg

"Zvi Netiv" <support@replace_with_domain.com> wrote in message

Hello Zvi
I don't think I used ResQ correctly. Why was it trying to detect
FAT? Came home a half hour later and it was still detecting fat
so I
made it finish. Here are the results. Is this what you wanted or
do
I need to run the program again.

RESQDISK ran alright and the data posted is good.

Evaluation Copy *************************************** CHS
mode W9x
******************* * R e s Q d i s k 576 *
* Hard Disk Rescue and Recovery *
Disk 1 * * Copyright (c) '90-04 NetZ Computing *
SeeThru
* ExtBIOS * * Virus Control, Disk & Data Recovery *
ON F9 * *********
***************************************

From the report header I can see that although I asked to
disconnect
all drives except the one under test, there was at least one
additional drive still connected!

*********************** Setup Diagnostics
************************
* Disk Type: WDC WD1600JB-00HUA0
* BIOS/CHS IDE/LBA
data *
* Number of Heads: 255 16
* Number of Cylinders: 1024 266305
* Sectors per Track: 63 63
* Disk Capacity in Mbytes: 8032 131071
* IDE Access Time: 44
msec
* Total sectors on drive:
268435455
******* Use Space to toggle between IDE and Ext.BIOS mode

No problem seen here.

CHS address: Cyl 0 Head 0 Sector 1
******************** Partition Table Layout
********************** *
* Partition Starting Ending Reserved
Total
* Boot Type Head Cyl. Sec. Head Cyl. Sec. Sectors
Sectors
*
* 7 1 0 1 254 1023 63 63
312576642*
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
* 0 0 0 0 0 0 0 0 0
*
******* Press Alt+B to see as boot sector, Alt+M to edit
********* Disk 1, Master Partition Sector,

No problem here either. The partition table is OK and shows that
the
drive contains a single NTFS partition of 156 GB.

Yet the important info is in what's missing here. If the drive
was
healthy, then RESQDISK should have reported here the parameters of
the NTFS boot sector of the single partition. Its absence tells
that
the content of sector 0/1/1 (CHS notation) isn't a valid boot
sector,
as predicted in previous posts.

[snip]

I had to stop the data recovery from EasyRecovery Pro. It was
taking
to long to write to the recovery drive/folder. (about 25 hrs was
the
estimate). The files I looked at had lost all structure even file
names were changed.

Expected too, as I explained in previous posts.

Of course I only used ERP's RAW recovery tool.
GetDataBack left most file names in tact but didn't near the info
back that ERP recovered. Very little was recovered with
GetDataBack.

All file recovery SW operate on the same principles and they fail
all
on the same problem, i.e. lack of contiguity of the files to
recover!
If one such package yields lots of broken files, then it's a waste
of
time and money to pursue this avenue and try several data recovery
packages on that drive.

Yet your last observation is encouraging on one aspect, i.e. the
many
good file *names* suggests that the MFT is probably undamaged!
But
you'll have to wait to know, until the boot sector is recovered.

Be warned that the following isn't the safest method to restore
the
boot sector, but given that there is just one NTFS partition on
that
drive, the drive is larger than 137 GB (which presents a problem
to
handling it under DOS), and the partition table is good, then the
following procedure is the simplest to fix that boot sector. I
also
recommend that you adhere to the instructions, without improvising
or
changing anything:

First, disconnect all drives except the one to fix.

Next, boot the computer from the XP setup CD, and press R when
prompted to start in repair mode.

From the repair console, run the command FIXBOOT and *nothing*
else!
This last comment is aimed to deter those that may advise you to
also
run FIXMBR. Just don't!

When done with FIXBOOT, shut down the PC, reconnect the drives,
restart Windows, and check if you can now access your files on the
160 GB drive.

Please report back here how things went.

Regards, Zvi

 

[Zvi Netiv]

FIXBOOT Restored the drive although I'm missing most files I was
hoping to regain.

Regaining access to the drive by restoring the boot sector confirms my
assessment as to what caused to lose it. Apparently, the boot sector wasn't the
only element that got damaged.

It imeadiatly ran chkdisk on system start. Chkdisk said: Deleting
orphan file record segment, up to about 60,000 + files. Then it said
verifying Indexes, then Inserting index entry, Replacing invalid
security ID, Inserting data attribute and correcting errors in boot
file. I missed some of them. I wonder if I should have stopped check
disk?

You shouldn't have let CHKDSK to start in the first place, by pressing a key
during the countdown before it started! You ran a long way to stumble just
before the finish line.

Chkdsk in XP's startup runs in auto repair mode and it doesn't let the user
decide to not repair its findings. It's possible that many of your files could
be copied of the drive if you didn't let Chkdsk to "fix" the file system.

Remember the problem happened when I renamed the Drive and at the
same time I was transfering a folder containing all my JPG images.
That folder is gone.

The Drive also Retained it's Drive letter (F) and I notice that the
Drive name change took affect. It now has a new name I choose.

It's funny that the one folder I had not yet transfered from the
drive remained intact. Although the top folder in the hierarchy
seemed to be renamed, (dir0000.chk) etc...the folders inside it
retained their complete folder names as well as file names but
folders were missing within thoose folders.

The dir0000x notation are the doing of Chkdsk.

Whats my next step? Data recovery software. What is the best?

Right now, except professional data recovery (expensive), you could try the data
recovery packages that you already purchased. Having regained access to the
drive should facilitate the process.

If what you are after is mostly JPGs, then here is a link to the program that
Robert Green wrote to recover JPG after having been hit by the LoveLetter worm
(the problem you face is similar). http://www.claymania.com/zefrjpg.html

Regards, Zvi

 

[Gregg OBanion]

Zvi, I want to thank you very much. It looks like I did drop the
ball at the finish line. I knew I shouldnt haver let CHKDisk run. It
started in the blink of an I and was well into running before I
realized the mistake so I just let it finish. I'll bet you if
Chkdisk hadn't run I would have recovered those files.

I'll post back here to let you know how the link you gave me below
works. If that doesn't work I'll try recovery software.

 

[Zvi Netiv]

[snip]

Anyone can lookup http://www.ctyme.com/intr/rb-0715.htm and see for themselfs.
Or Information Technology - BIOS Enhanced Disk Drive Services – 2 (EDD-2)
http://www.t13.org/project/d1484r3.pdf, page 13, 14.

And lookup the 16,383 32,767 and 65,535 numbers in: D1410r0a
Information Technology AT Attachment with Packet Interface - 6 (ATA/ATAPI-6)
http://www.t13.org/project/d1410r0a.pdf

Blah, blah, blah ...

In case you haven't noticed, this thread ended when I resolved what caused the
partition to disappear. To which you contributed absolutely nothing.

 

[Folkert Rienstra]

[snip] [unsnip]

Introductory context restored. Typical how people like Netiv always have to snip that to
make themselves believable, the sure sign that such person obviously has something to hide.


(Or in the words of EDD-2: The geometry returned in bytes 4-15 shall be valid)


Your deliberate snipping of the quoted error tells it all Netiv.
You are just posturing.
You are the 'clueless' one that obviously didn't check Int 13-AH=48h's
information buffer result of the word at offset 2, bit one, for the validity
of the geometry as returned in bytes 4-15: Number of default cylinders,
Number of default heads and Number of default sectors.

Blah, blah, blah ...

Yup, what else can one say if one's nose is rubbed in the facts.

In case you haven't noticed, this thread ended when I resolved what caused the
partition to disappear.

Even a broken clock is right on time twice a day, every day of
the year, year in, year out, Doesn't mean it's actually running.

To which you contributed absolutely nothing.

So what, didn't make the errors in your report any less wrong.
Or the risk one takes running your apps when you can't get your facts right.