screwed up partition and data recovery

[Sergio Graziosi]

to avoid having an
NTFS boot sector in the beginning of the partition, I use 27 so other
partitioning tools will not assume that the partition is a normal
hidden NTFS partition.

Nice, agreed.

The parameters are explained on the screen by typing:

set findpart=edit
findpart editpart /?
set findpart=

I see, did you realize that it takes a brave person to enter "edit"
mode before even viewing the parameters?

The batch file makes an ID 27 partition from the second sector of the
disk 2 to the end of the disk 2 (disks numbered from 1).

Thanks, I was quite close indeed.
I've applied the batch and played a little with your tools taking care
not to use edit mode again. Here are some random results:

****summary****
FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/0/2 LBA: 1

Directories: 4046
Files: 109031
Trees: 3555
Adjusted: 16
Exe/dll files: 2089
Exe/dll files signature: 3
Not referenced files: 106323
Cluster KB: 0.5
MFT record used: None
MFT offset MB: 3072
Listed files MB: 143253
********

********
Findfile, version FP 4.43.
Copyright Svend Olaf Mikkelsen, 2004.

Searches for file records and index records. The T field
contains F for file records, D for directory file records,
or I for index records. Index records do not contain
information about file locations.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

Start cylinder: 0 End cylinder: 30514 Index records not shown.

--------- CHS ----- LBA T -Record Cluster Name
0 1 1 63 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 404259596
0 1 17 79 F 0 6291456 $MFT
Size: 116719616
Allocated: 116719616
Fragments: 1
Clusters: 226496
Cluster KB: Unknown
Time: 2003-09-09 13:18:36
0 1 19 81 F 0 16 $MFTMirr
Size: 4096
Allocated: 4096
Fragments: 1
Clusters: 8
Cluster KB: 0.5
Boot CHS: 0 1 1
Offset MB: 0
Time: 2003-09-09 13:18:36
0 1 21 83 F 0 24 $LogFile
0 1 23 85 F 0 Small $Volume
1 185 38 27757 F 0 Small
#0002_sp_Av_ra_no_coAr_alt_best_100ms_co
5 115 16 87585 F 0 Small
BOB_LowV_smoot_sigma_rho.fig
<SNIP>
432 9 56 6940702 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 469017611
8581 169 47 137864458 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 406299851
16818 130 37 270189396 F 0 Small ~$arning (1) 14 01
2003.doc
29194 254 63 469017674 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 469017611
**********

*******Dirs******
FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/0/2 LBA: 1

------Date ----Time -------Size ---Flags Name
5
19 INPRO\
<snip>
113218 fig1\

0

Directories: 4046
Files: 109031
Trees: 3555
Adjusted: 16
Exe/dll files: 2089
Exe/dll files signature: 3
Not referenced files: 106323
Cluster KB: 0.5
MFT record used: None
MFT offset MB: 3072
Listed files MB: 143253
**************

Seemed promising so I've tried:
findpart findntfs 2 0 0 2 XXX.txt dirs copy 83623
to retrieve a folder known to contain bad files. Output:

**************

FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/0/2 LBA: 1

------Date ----Time -------Size ---Flags Name
83623 paper 3 & 4\

Directories: 4046
Files: 2708
Trees: 3555
Adjusted: 16
Exe/dll files: 158
Exe/dll files signature: 1
Copied files: 0
Cluster KB: 0.5
MFT record used: None
MFT offset MB: 3072
Listed files MB: 3480
*************

0 files copied???
Second try:
findpart findntfs 2 0 1 1 XXX.txt dirs copy 83623
It is exactly the same command but with the old/real partition start
CHS, this time I get:

************
FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/1/1 LBA: 63

------Date ----Time -------Size ---Flags Name
83623 oldisk E\Alberto\MEA\paper 3 & 4\
<SNIP>
88560 oldisk E\Alberto\MEA\paper 3 & 4\sing neurone
analysis\parallelo0613_0615\

Directories: 4045
Files: 103375
Trees: 5
Exe/dll files: 2089
Exe/dll files signature: 1278
Copied files: 4221
Cluster KB: 0.5
MFT cluster no: 6291456
MFT size: 116719616
MFT cluster bytes: 512
Listed files MB: 141092
************

WOW! but as expected the bad files recovered were not magically fixed
up.
The noboot and nomftrecord options did not help.
At this point this is what I think. I need to repair the damage
produced by Win2000 chkdsk. Probably the physical address of files was
re-arranged in the MFT in order to fit in the smaller disk size seen
by windows, or in other words, all those entries that referred to
addresses outside the "new/wrong" boundaries were simply deleted. This
means that my only hope is to find a backup MFT in the last part of
the drive, the one that was "left over"/forgotten. Does this idea make
any sense? If it does, how do I proceed?
If it doesn't is there any hope left?
Remember that I don't have lost files (i.e. deleted files) but many
files are corrupted, meaning that their content does not make any
sense. Examples: no recognizable text in word files viewed with
notepad, missing %PDF as the first line of PDFs, no image header for
TIFF and so on.

Sorry for the long post,
Sergio

 

[Svend Olaf Mikkelsen]

CHS 0/0/2 LBA: 1

Wrong parameters. The NTFS partition location is CHS 0/1/1

FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/1/1 LBA: 63

------Date ----Time -------Size ---Flags Name
83623 oldisk E\Alberto\MEA\paper 3 & 4\
<SNIP>
88560 oldisk E\Alberto\MEA\paper 3 & 4\sing neurone
analysis\parallelo0613_0615\

Directories: 4045
Files: 103375
Trees: 5
Exe/dll files: 2089
Exe/dll files signature: 1278
Copied files: 4221
Cluster KB: 0.5
MFT cluster no: 6291456
MFT size: 116719616
MFT cluster bytes: 512
Listed files MB: 141092

WOW! but as expected the bad files recovered were not magically fixed
up.
The noboot and nomftrecord options did not help.
At this point this is what I think. I need to repair the damage
produced by Win2000 chkdsk. Probably the physical address of files was
re-arranged in the MFT in order to fit in the smaller disk size seen
by windows, or in other words, all those entries that referred to
addresses outside the "new/wrong" boundaries were simply deleted. This
means that my only hope is to find a backup MFT in the last part of
the drive, the one that was "left over"/forgotten. Does this idea make
any sense? If it does, how do I proceed?
If it doesn't is there any hope left?
Remember that I don't have lost files (i.e. deleted files) but many
files are corrupted, meaning that their content does not make any
sense. Examples: no recognizable text in word files viewed with
notepad, missing %PDF as the first line of PDFs, no image header for
TIFF and so on.

Sorry for the long post,
Sergio

There is no backup Master File Table. The MFT mirror is basically just
a 1024 bytes file record for the MFT itself (and a few more files).

If a file was copied, but wrong, it indicates that the file was
written 128 GB lower than intended, or that the file record for the
file was changed by chkdsk while keeping the number of clusters
correct. I have not previously verified that chkdsk can do that.

It seems as you ran a Findpart Findfile search for the entire disk
with filenames in the output file?

Can you find a line in the Findfile output, which contains a file
which was copied, but not correct, and copy/paste it here? You can
omit the file name.

In the meantime I will consider if I can add a feature to print the
cluster numbers for each file. Alternatively we can retrieve the 1024
bytes file record using a Findpart Getsect command, and I can inspect
the file record manually.

 

[Svend Olaf Mikkelsen]

If a file was copied, but wrong, it indicates that the file was
written 128 GB lower than intended, or that the file record for the
file was changed by chkdsk while keeping the number of clusters
correct. I have not previously verified that chkdsk can do that.

Or that the content of the file was overwritten by other files, which
were written 128 GB lower than expected.

 

[Sergio Graziosi]

There is no backup Master File Table. The MFT mirror is basically just
a 1024 bytes file record for the MFT itself (and a few more files).

Obviously you are right.

If a file was copied, but wrong, it indicates that the file was
written 128 GB lower than intended,

I don't understand this sentence, but anyway it may help to know that
most of these files were already there and working before the trouble
begun.

or that the file record for the
file was changed by chkdsk while keeping the number of clusters
correct. I have not previously verified that chkdsk can do that.

This is what I fear :-(.

Can you find a line in the Findfile output, which contains a file
which was copied, but not correct, and copy/paste it here? You can
omit the file name.

There you go:
402 10 6 6458765 D 0 16221264 paper 3 & 4
402 10 8 6458767 F 0 comments_paolo.doc

The first line is the folder that contains the broken file, I did not
snip any lines BTW. The command line to attempt the recovery was:
findpart findntfs 2 0 1 1 XXX.txt dirs copy 83623
where 83623 is the dir ID of the "paper 3 & 4" folder, as found in the
output of a previous "findntfs [..] dirs" command. I hope this is what
you were asking for.

In the meantime I will consider if I can add a feature to print the
cluster numbers for each file. Alternatively we can retrieve the 1024
bytes file record using a Findpart Getsect command, and I can inspect
the file record manually.

We can have a try for one file, if you wish to waste your time with
me, but in any case, you will have to teach me how to do it, we are
talking about n*100 files. Are you really suggesting that it is
possible to locate all the data belonging to a given file even without
a correct MFT entry? Amazing. I thought that in NTFS the actual
location of the data file portions was stored *only* in the MFT.
Thanks once again,

Sergio

 

[Svend Olaf Mikkelsen]

There you go:
402 10 6 6458765 D 0 16221264 paper 3 & 4
402 10 8 6458767 F 0 comments_paolo.doc

I assume the file comments_paolo.doc was copied, but the content not
correct.

Assuming the problem disk is still disk number 2, you can do:

findpart getsect 2 402 10 8 2 fp-b.bin

and mail me the file fp-b.bin as attached file (eventually zipped to
enhance the change of transfer success), which should contain the 1024
bytes file record for the file comments_paolo.doc. For a small file
the file record can contain the actual file content, but I assume that
is not the case here.

You can verify the content of fp-b.bin using the command:

edit /64 fp-b.bin

The file contains a header with the disk location it is copied from.

 

[Svend Olaf Mikkelsen]

I assume the file comments_paolo.doc was copied, but the content not
correct.

Assuming the problem disk is still disk number 2, you can do:

findpart getsect 2 402 10 8 2 fp-b.bin

and mail me the file fp-b.bin as attached file (eventually zipped to
enhance the change of transfer success), which should contain the 1024
bytes file record for the file comments_paolo.doc. For a small file
the file record can contain the actual file content, but I assume that
is not the case here.

You can verify the content of fp-b.bin using the command:

edit /64 fp-b.bin

The file contains a header with the disk location it is copied from.

I received the NTFS file record, and stored it at CHS 0/0/40 on my
disk. Using a yet internal FindNTFS version, I have:

Findfile, version FN 1.48.
Copyright Svend Olaf Mikkelsen, 2004.

Start cylinder: 0 End cylinder: 0 Index records not shown.

--------- CHS ----- LBA T -Record Cluster Name
0 0 40 39 F 0100163052 comments_paolo.doc
24064
100163052 47

Showing that the file size of comments_paolo.doc is 24064 bytes, and
that the location is 47 clusters from cluster 100163052. In this case
the cluster size is 512 bytes. Which may confuse some recovery
programs, including FindNTFS, but I do not know, since the normal
cluster size would be larger.

If this file was copied using this information, and was wrong, one
question is if chkdsk could change the datarun (cluster numbers),
while keeping the number of clusters correct. It does not seem likely,
but may be possible.

This location is below 128 GB, so one other possibility is that the
file was overwritten due to the 128 GB problem. But there is nothing
else to do than examine. I will release a FindNTFS version, which will
give the information above, and with a "wrap128gb" option, which will
simulate the 128 GB wrap in order to be able to recover files, that
were written 128 GB too low.

The location of cluster 100163052 should be sector 63 (boot sector) +
100163052 = 100163115, in this case CHS 6234/220/46, since the cluster
size is 1 sector.

findpart getsect 2 6234 220 46 47 test.bin noheader

But that should be the same as already copied (except for the exact
size).

 

[Svend Olaf Mikkelsen]

FindNTFS, version FP 4.43 - for Windows 95/98/ME/NT/2000/XP.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

CHS 0/1/1 LBA: 63

------Date ----Time -------Size ---Flags Name

Directories: 4045
Files: 103375
Trees: 5
Exe/dll files: 2089
Exe/dll files signature: 1278
Copied files: 4221
Cluster KB: 0.5
MFT cluster no: 6291456
MFT size: 116719616
MFT cluster bytes: 512
Listed files MB: 141092

One significant value here is the "Exe/dll files signature." Each
(almost all) exe or dll files have "MZ" in the first two bytes.
Counting the number of signature matches help estimate the condition
of the partition. In this case we have a match for 1278 of 2089 files.

One thing that could be attempted is to run the search with a 128 GB
wrap. If you want to do that, you can get FindNTFS version 1.48 in

http://www.partitionsupport.com/fntfs148.zip

and do:

findntfs 2 0 1 1 summary fp-c.txt wrap128gb


It could be said that since a file after the MFT, before 128 GB, could
not be copied, there is no certain sign that a wrap occurred.

The same FindNTFS version has an option to print file size and cluster
numbers in a FindNTFS Findfile search. Example to search the first
1001 cylinders on disk 2:

findntfs findfile 2 0 1000 datarun 0 filenames files-d.txt

The parameter after "datarun" is the cluster size in kilobytes, with 0
for 0.5 KB.

 

[Sergio Graziosi]

One significant value here is the "Exe/dll files signature." Each
(almost all) exe or dll files have "MZ" in the first two bytes.
Counting the number of signature matches help estimate the condition
of the partition. In this case we have a match for 1278 of 2089 files.

Mpft, I guessed something like that, and I've tried to ignore its
meaning.

One thing that could be attempted is to run the search with a 128 GB
wrap. If you want to do that, you can get FindNTFS version 1.48 in

http://www.partitionsupport.com/fntfs148.zip

and do:

findntfs 2 0 1 1 summary fp-c.txt wrap128gb

Done:
Exe/dll files: 2089
Exe/dll files signature: 1278

No good news here. In fact the output numbers are 100% the same of the
analogous command without the wrap128gb option.

It could be said that since a file after the MFT, before 128 GB, could
not be copied, there is no certain sign that a wrap occurred.

I'm not following you here... 1) I am not sure of what you mean by 128
GB Wrap, 2) as a consequence I do not know how we are supposed to
detect it.

The same FindNTFS version has an option to print file size and cluster
numbers in a FindNTFS Findfile search. Example to search the first
1001 cylinders on disk 2:

findntfs findfile 2 0 1000 datarun 0 filenames files-d.txt

Ok, I did this. To my eyes it is equivalent to:
"search the cylinders from 0 to 1000 for MFT entries and report the
position of every datarun therein". Really cool, and may allow us to
retrieve each single file if the datarun addresses were known to be
wrong of a predictable number of CHS, right? But in fact, at this
stage, we do not even know if there may be a predictable number IMHO.
The result of this test is a huge "file&dir" list with datarun
addresses, the only thing I could check is the report about our
"comments_paolo.doc" test file. They are the same as you reported in
the previous post.
BTW the "findpart getsect 2 6234 220 46 47 test.bin noheader"
appears to return exactly the same file as retrieved with my previous
trial
"findpart findntfs 2 0 1 1 XXX.txt dirs copy 83623"

FWIW I've tried also "findntfs findfile 2 1000 2000 datarun 0
filenames file s-c1.txt" and "findntfs findfile 2 2000 30514 datarun 0
filenames file s-c2.txt" (before lunch .
s-c1.txt reports an expected "None found" whyle s-c2.txt is:
***********
Findfile, version FN 1.48.
Copyright Svend Olaf Mikkelsen, 2004.

Searches for file records and index records. The T field
contains F for file records, D for directory file records,
or I for index records. Index records do not contain
information about file locations.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

Start cylinder: 2000 End cylinder: 30514 Index records not shown.

--------- CHS ----- LBA T -Record Cluster Name
8581 169 47 137864458 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 406299851
16818 130 37 270189396 F 0 Small ~$arning (1) 14 01
2003.doc
29194 254 63 469017674 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 469017611
***********

I wonder if it means something.

In addition I did an other trial: I thought that chkdsk may have
corrected the entry of dataruns reported after the 128 limit simply by
subtracting 128 GB to their values. In this case (a wild guess, I
know), I should be able to use getsect to fish out the data from its
real location.
128 GB should be 268435456 sectors of 512 bytes (I did find this in
"http://www.pcguide.com/ref/hdd/bios/sizeGB128-c.html"). In CHS space
this should convert to 16709 85 16, the math is mine so may be wrong.
Adding this to the MFT entry of the only datarun for
comments_paolo.doc allowed me to try:
"findpart getsect 2 22944 50 63 47 test1.bin noheader".
Apparently I was wrong, because the resulting file is just a dull
series of zeros. Getting some other sectors more or less randomly
around the previous attempt gave always the same result,
000000000000000... (Hex values).
If you are still willing to loose your time with my hopeless situation
I'll be more than happy to perform any other trial that you might
consider meaningful.

Gratefully,
Sergio

 

[Svend Olaf Mikkelsen]

Findfile, version FN 1.48.
Copyright Svend Olaf Mikkelsen, 2004.

OS: Windows 5.0.2195 Service Pack 4

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

Start cylinder: 2000 End cylinder: 30514 Index records not shown.

--------- CHS ----- LBA T -Record Cluster Name
8581 169 47 137864458 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 406299851
16818 130 37 270189396 F 0 Small ~$arning (1) 14 01
2003.doc
29194 254 63 469017674 Boot or backup
Sectors per cluster: 1
MFT cluster: 6291456
MFT Mirror cluster: 16
Partition sectors: 469017611

I wonder if it means something.

Disk: 2 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK


We did see these findings in a previous output. It can be noted that
137864458 + 2^28 - 63 is 406299851.

Meaning that the boot sector at CHS 8581/169/47 is a backup boot
sector (the last sector in a partition) written 128 GB too low. The
number of sectors in the partition does however not match the current
partition.

The other backup bootsector found also does not match the current
partition. The backup boot sector of the current partition was not
located.

Well, it is a long thread. I read the first message again. Partition
Magic was mentioned. It could be an undetected Partition Magic crash,
and then we have been on the wrong track. I will think about it. If we
are patient, the goal is to recover the data or figure out exactly why
it cannot be done.

 

[Sergio Graziosi]

We did see these findings in a previous output. It can be noted that
137864458 + 2^28 - 63 is 406299851.

Meaning that the boot sector at CHS 8581/169/47 is a backup boot
sector (the last sector in a partition) written 128 GB too low. The
number of sectors in the partition does however not match the current
partition.

It took me a while but I do follow you here.

The other backup bootsector found also does not match the current
partition. The backup boot sector of the current partition was not
located.

Well, it is a long thread. I read the first message again.

I did it too...

Partition
Magic was mentioned. It could be an undetected Partition Magic crash,
and then we have been on the wrong track.

We are getting close to the point. My bet is that we are dealing with
more errors superimposed, the 128 limit is only part of the trouble
and probably its origin.

I will think about it. If we
are patient, the goal is to recover the data or figure out exactly why
it cannot be done.

I really hope to find out what happened, at least to produce a well
documented story for the legitimate owner of the lost data. The good
thing is that your help is a great stimulus for me to learn more, and
hopefully I will be able either not to repeat the same errors or to
repair them with more ease.
However, at this point I'm completely dependent on you or other
forum-fellows to somehow continue the data-quest.

Cheers,
Sergio

-----------------------
Sergio Graziosi
Neurobiology Sector
SISSA/ISAS Trieste
Tel:
+39/040/3787256
www.sissa.it/~graziosi
-----------------------