Sign in with
Sign up | Sign in
Your question

screwed up partition and data recovery

Last response: in Storage
Share
Anonymous
a b G Storage
May 24, 2004 8:39:35 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Here's my problem history:
-Installed a 250 GB Maxtor HD on a mobo via an on-board promise
controller: one big NTFS partition only. All worked.
-Users filled it up, they produce 4-10 Gb of data per day, making it
impossible to find a cost-effective backup strategy.
-The on-board promise controller stopped to work.
-I simply switched the disk to the ordinary ATA controller. The BIOS
was not reporting the disk size even with the last update (supposed to
support it).
-However windows2000 saw the disk & partition correctly.
-For other reasons I was asked to re-partition the disk, with
PartitionMagic. No matter how I tried but only the first partition was
visible to the OS. So I re built a huge partition, checked a few files
and returned the PC to its users (shame on me).
-Nothing wrong until windows does a chkdsk on an unattended boot-up.
-The event viewer reports a list of fixes on corrupted files so long
that is not complete.
-Apparently all the fixed files are now corrupted (still there,
reasonable size but unrecognizable format(s)).
-The size of the partition is reduced to some 194GB and so is the disk
(as reported in the mmc disk manager).
-I've installed it on a new PC, in order to have the disk recognized
perfectly from BIOS - worked. Still the OS (always win2000 SP4) sees
the disk as smaller.
-I've ran the maxtor disk checking utility and no error was detected
(for obvious reasons I've skipped the LowLevelFormat test).
-Testdisk form www.cgsecurity.org *does* recognize the error on the
MBR/partition table.
Now the question: is it possible to recover the damaged files?
Apparently, during or after the re-partitioning attempts, something
went wrong and all the files that were outside the "new" borders (of
what windows thinks is the disk size) have been broken down (thanks to
chkdsk). All the missing parts are probably still there at the end of
the disk, but is there a way to recover them at this point? Simply
correcting the MBR will not do the trick IMHO, I may be able to dig
out the lost raw data but not to fix the files killed by chkdsk.
Any idea?

Thanks very much and sorry for the long post,
Sergio Graziosi

-----------------------
Sergio Graziosi
Neurobiology Sector
SISSA/ISAS Trieste
www.sissa.it/~graziosi
-----------------------
Anonymous
a b G Storage
May 25, 2004 9:11:13 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

confusing update:
Svend's Findpart output (using windows version)
*************
Disk: 3 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

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

No FATs found.

Partitions according to partition tables on third harddisk:

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

If I got it right it is telling me that the partition is *larger* than
the disk itself. But in fact I know it's the opposite.
Strangely enough it is the same also with PartitionInfo from
PartitionMagic8:

****
Error #109: Partition ends after end of disk.
ucEndCylinder (25163) must be less than 16709.
****

In fact this may seem weird but I guess it can be explained: the
partition table is still right but windows thinks the disk to be
smaller.

Next step: I'm going tu run Findpart from dos and see if anything
changes. I'll post the results soon. I'm also checking again the bios
recognition FWIW.
Cheers,
Sergio
Anonymous
a b G Storage
May 25, 2004 11:07:38 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

And here comes the dos findpart report:
********************
OS: DOS 6.22

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

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
25291 0 33 Second FAT not found.

Partitions according to partition tables on third harddisk:

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

If all this mess weren't my fault it would be worth a good laugh.
Would restoring the backup boot sector entry help fixing the messed up
files?
Why on earth am I getting different results if running findpart from
windows or dos? I'm trying to evoke the mighty Mikkelsen you see...
Take care,
Sergio
Related resources
Anonymous
a b G Storage
May 26, 2004 2:26:08 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 25 May 2004 07:07:38 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>OS: DOS 6.22
>
>Disk: 3 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367
>
>--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
> 0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
> 0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK
>
>------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 25291 0 33 Second FAT not found.
>
>Partitions according to partition tables on third harddisk:
>
>--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK

You should not cut the Findpart version number and Windows version
(other output). And when a 128 GB problem is present, you should not
cut output from other disks.

The disk is seen as full size in DOS, but not in Windows.

The partition table, and the boot sector of the 197392 MB NTFS
partition are OK. The internal condition of the partition is not
known.

A 40978 MB FAT32 partition, which may be internally OK, but which is
not in the partition tables is located at CHS 25291/0/1.

If we should do something about this case in the newsgroup, next step
would be that you do in Windows:

findpart tables fp-a.txt

and insert the output from fp-a.txt.

Then I will make a batch file to hide the partition on the disk in the
partition tables, and when done, the disk size problem should be
solved and further examination made.
--
Svend Olaf
Anonymous
a b G Storage
May 26, 2004 5:28:10 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40b3c446.12362119@dtext.news.tele.dk>...
> You should not cut the Findpart version number and Windows version
> (other output).

You are right: 4.43 for windows and 4.42 DOS.

> And when a 128 GB problem is present, you should not
> cut output from other disks.

I did ask findpart to look only at the troublesome HD. (the other HDs
I have are all smaller than 100 GB). But you are right again, I seem
to have underestimated the 128 GB limitation.

> The disk is seen as full size in DOS, but not in Windows.
>
> The partition table, and the boot sector of the 197392 MB NTFS
> partition are OK. The internal condition of the partition is not
> known.

Before we get to the details I'll post the tables output, but you'll
have to wait 24h since today I don't have physical access to the
affected system.

<...snip...>
> Then I will make a batch file to hide the partition on the disk in the
> partition tables, and when done, the disk size problem should be
> solved and further examination made.

Hide what exactly?
Thanks very much anyway, your support is really appreciated,
Sergio
Anonymous
a b G Storage
May 27, 2004 3:15:56 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Sergio Graziosi" <sgrazios@email.it> wrote in message news:f3ac2e67.0405250607.514d4de9@posting.google.com...
> And here comes the dos findpart report:
> ********************
> OS: DOS 6.22
>
> Disk: 3 Cylinders: 30515 Heads: 255 Sectors: 63 MB: 239367
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 07 63404259597197392 0 1 1 25163 254 63 B OK
> 0 - 0C406299915 83923560 40978 25291 0 1 30514 254 63 B OK
> 0 - 07 63469017612229012 0 1 1 29194 254 63 BU OK
>
> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 25291 0 33 Second FAT not found.
>
> Partitions according to partition tables on third harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK
> ********************
>
> If all this mess weren't my fault it would be worth a good laugh.
> Would restoring the backup boot sector entry help fixing the messed up
> files?
> Why on earth am I getting different results if running findpart from
> windows or dos?

> I'm trying to evoke the mighty Mikkelsen you see...

What, he doesn't respond to email, does he?

> Take care,
> Sergio
Anonymous
a b G Storage
May 27, 2004 3:41:39 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Sergio Graziosi" <sgrazios@email.it> wrote in message news:f3ac2e67.0405250411.7144414c@posting.google.com...
> confusing update:
> Svend's Findpart output (using windows version)
> *************
> Disk: 3 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 07 63404259597197392 0 1 1 25163 254 63 B OK?
>
> No FATs found.
>
> Partitions according to partition tables on third harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
> *************
>
> If I got it right it is telling me that the partition is *larger* than
> the disk itself. But in fact I know it's the opposite.

> Strangely enough it is the same also with PartitionInfo from PartitionMagic8:

So they are both flawed in the same department.
Which isn't really surprising when they look so very similar.

>
> ****
> Error #109: Partition ends after end of disk.
> ucEndCylinder (25163) must be less than 16709.
> ****
>
> In fact this may seem weird but I guess it can be explained: the
> partition table is still right but windows thinks the disk to be smaller.

The conclusion is still wrong.
Obviously the drive itself isn't checked and the info is gathered from
the OS or BIOS. Clearly the apps need to be updated to indicate whether
the partition table is in error or that the BIOS or OS is.

>
> Next step: I'm going tu run Findpart from dos and see if anything changes.
> I'll post the results soon. I'm also checking again the bios recognition FWIW.
> Cheers,
> Sergio
Anonymous
a b G Storage
May 27, 2004 4:18:36 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40b3c446.12362119@dtext.news.tele.dk>...
> You should not cut the Findpart version number and Windows version
> (other output). And when a 128 GB problem is present, you should not
> cut output from other disks.
<snip>
> If we should do something about this case in the newsgroup, next step
> would be that you do in Windows:
>
> findpart tables fp-a.txt
>
> and insert the output from fp-a.txt.

And here we go... I feel a just like an idiot. I didn't consider the
128 problem because I new I had the IAA installed. It was version 1.x.
(Ha Ha) And here is the tables output:

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

OS: Windows 5.0.2195 Service Pack 4 Partition tables:

Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63 40965687 20002 0 1 1 2549*254 63 OK OK
0 2 0F 40965750 3100545 1513 2550* 0 1 2742*254 63 OK
0 3 07 44066295 76019580 37118 2743* 0 1 7474*254 63 OK OK

2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK

Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069

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

The disk n^2 is the troublesome one. Now take a look at the disk after
the installation of IAA 2.2:

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

OS: Windows 5.0.2195 Service Pack 4 Partition tables:

Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644

-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
0 1*07 63 40965687 20002 0 1 1 2549*254 63 OK OK
0 2 0F 40965750 3100545 1513 2550* 0 1 2742*254 63 OK
0 3 07 44066295 76019580 37118 2743* 0 1 7474*254 63 OK OK

2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK

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
*****************

Looking at the positive side I may say that at least one problem has
been solved. Let me remind you that it is very likely that the last
part of the disk *does* contain valuable data from the original huge
partition.

> Then I will make a batch file to hide the partition on the disk in the
> partition tables, and when done, the disk size problem should be
> solved and further examination made.

I don't quite follow you here. If you are really so kind to send a
batch personalized for my means I suggest that you also help me
understanding what your strategy is, I know it would be the difficult
part :-(.

Thanks,
Sergio
Anonymous
a b G Storage
May 27, 2004 4:18:37 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Sergio Graziosi" <sgrazios@email.it> wrote in message news:f3ac2e67.0405262318.32c77407@posting.google.com...
> svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40b3c446.12362119@dtext.news.tele.dk>...
> > You should not cut the Findpart version number and Windows version
> > (other output). And when a 128 GB problem is present, you should not
> > cut output from other disks.
> <snip>
> > If we should do something about this case in the newsgroup, next step
> > would be that you do in Windows:
> >
> > findpart tables fp-a.txt
> >
> > and insert the output from fp-a.txt.
>
> And here we go... I feel a just like an idiot. I didn't consider the
> 128 problem because I new I had the IAA installed. It was version 1.x.
> (Ha Ha) And here is the tables output:
>
> *****************
> Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
[snip]
>
> Disk: 2 Cylinders: 16709 Heads: 255 Sectors: 63 MB: 131069
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*07 63404259597197392 0 1 1 25163*254 63 OK OK?
> ****************
>
> The disk n^2 is the troublesome one.
> Now take a look at the disk after the installation of IAA 2.2:
>
> ****************
> Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
[snip]
>
> 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 63 404259597 197392 0 1 1 25163*254 63 OK OK
> *****************
>
> Looking at the positive side I may say that at least one problem has been
> solved. Let me remind you that it is very likely that the last part of
> the disk *does* contain valuable data from the original huge partition.
>
> > Then I will make a batch file to hide the partition on the disk in the
> > partition tables, and when done, the disk size problem should be solved
> > and further examination made.
>

> I don't quite follow you here. If you are really so kind to send a batch
> personalized for my means I suggest that you also help me understanding
> what your strategy is, I know it would be the difficult part :-(.

One can always hope.

It sometimes helps to ask the question again.
And even then you may get a completely incomprehensible answer.

>
> Thanks,
> Sergio
Anonymous
a b G Storage
May 27, 2004 6:54:31 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 27 May 2004 00:18:36 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
>Copyright Svend Olaf Mikkelsen, 1999-2004.
>
>OS: Windows 5.0.2195 Service Pack 4 Partition tables:
>
>Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644
>
>-PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
> 0 1*07 63 40965687 20002 0 1 1 2549*254 63 OK OK
> 0 2 0F 40965750 3100545 1513 2550* 0 1 2742*254 63 OK
> 0 3 07 44066295 76019580 37118 2743* 0 1 7474*254 63 OK OK
>
> 2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK
>
>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

From the original description it is not possible to predict what
happened, so there is nothing else to do than examine.

In my opinion it is necessary to hide the partition before
examination, since it is too confusing and dangerous if changes to the
partition happens during the examination, and eventually file copying.

If the partition is hidden you will not be able to access any files
using the operating system. It is done by editing the partition table,
so Windows will not see the partition, while the area containing the
partition is still reserved so new partitions cannot be made.

If you want to hide the partition, you can download sergio1.bat in

http://inet.uni2.dk/~svolaf/sergio1.zip

and run sergio1.bat, which contains:

set findpart=edit
findpart 2 0 1 - 27 0 0 2 30514 254 63 0 30515 255 63 26
set findpart=
findpart tables fp2-1.txt

The change will be effective after reboot.

You will depend on me to make another batch file to make the partition
visible to Windows 2000 again.
--
Svend Olaf
Anonymous
a b G Storage
May 27, 2004 6:54:32 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Svend Olaf Mikkelsen" <svolaf@inet.uni2.dk> wrote in message news:40b70122.7669497@dtext.news.tele.dk...
> On 27 May 2004 00:18:36 -0700, sgrazios@email.it (Sergio Graziosi) wrote:
>
> > Findpart, version 4.43 - for Windows 95/98/ME/NT/2000/XP.
> > Copyright Svend Olaf Mikkelsen, 1999-2004.
> >
> > OS: Windows 5.0.2195 Service Pack 4 Partition tables:
> >
> > Disk: 1 Cylinders: 7476 Heads: 255 Sectors: 63 MB: 58644
> >
> > -PCyl N ID -----Rel -----Num ---MB -Start CHS- --End CHS-- BS CHS
> > 0 1*07 63 40965687 20002 0 1 1 2549* 254 63 OK OK
> > 0 2 0F 40965750 3100545 1513 2550* 0 1 2742* 254 63 OK
> > 0 3 07 44066295 76019580 37118 2743* 0 1 7474* 254 63 OK OK
> >
> > 2550 1 07 63 3100482 1513 2550 1 1 2742 254 63 OK OK
> >
> > 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 63 404259597 197392 0 1 1 25163* 254 63 OK OK
>
> From the original description it is not possible to predict what
> happened, so there is nothing else to do than examine.
>
> In my opinion it is necessary to hide the partition before examination,
> since it is too confusing and dangerous if changes to the partition
> happens during the examination, and eventually file copying.
>
> If the partition is hidden you will not be able to access any files
> using the operating system. It is done by editing the partition table,
> so Windows will not see the partition, while the area containing the
> partition is still reserved so new partitions cannot be made.
>
> If you want to hide the partition, you can download sergio1.bat in
>
> http://inet.uni2.dk/~svolaf/sergio1.zip
>
> and run sergio1.bat, which contains:
>
> set findpart=edit
> findpart 2 0 1 - 27 0 0 2 30514 254 63 0 30515 255 63 26
> set findpart=
> findpart tables fp2-1.txt
>
> The change will be effective after reboot.
>

> You will depend on me to make another batch file to make the partition
> visible to Windows 2000 again.

Not really.

> --
> Svend Olaf
Anonymous
a b G Storage
May 28, 2004 2:01:11 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Wed, 26 May 2004 23:15:56 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>What, he doesn't respond to email, does he?

The user (including you?) decides what to put in the newsgroup. The
advantage of the newsgroup is that we learn something about the 128 GB
problem, and that it for anyone interested can be found by search
afterwards.

I wonder how large a percentage of the 2000/XP 128 GB problems we see
here. One of 1000? 10.000? 100.000? It may be a major problem.
--
Svend Olaf
Anonymous
a b G Storage
May 28, 2004 5:49:58 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40b70122.7669497@dtext.news.tele.dk>...

> From the original description it is not possible to predict what
> happened, so there is nothing else to do than examine.

Agreed.

> In my opinion it is necessary to hide the partition before
> examination, since it is too confusing and dangerous if changes to the
> partition happens during the examination, and eventually file copying.

And the examination will be done by means of...?

> If the partition is hidden you will not be able to access any files
> using the operating system. It is done by editing the partition table,
> so Windows will not see the partition, while the area containing the
> partition is still reserved so new partitions cannot be made.

That is clear.

> If you want to hide the partition, you can download sergio1.bat in
>
> http://inet.uni2.dk/~svolaf/sergio1.zip
>
> and run sergio1.bat, which contains:
>
> set findpart=edit
> findpart 2 0 1 - 27 0 0 2 30514 254 63 0 30515 255 63 26
> set findpart=
> findpart tables fp2-1.txt

Ok, since the purpose of my posts here is also to let other people
learn from my mistakes I am not afraid to ask for clarifications:
Your documentation on www. partitionsupport.com is useful but way far
from complete. IOW it does not allow me to understand what all the
numbers mean. Please correct me as needed and possibly fill in the
blanks. Let's go in order:
-"findpart 2 0 1"= work on disk 2, from the MBR partition table, first
entry,

- "-" = dunno, "27" = set partition ID to 27 useful to hide the
partition,

-"two spaces" I wonder if that means something, "0 0 2" = set
partition start to CHS 0,0,2. It appears that we are having a double
protection: changing the ID (but you report that win2000 does not
respect it) so we also report a false partition start 0,0,2 instead of
0,1,1. I guess that this is enough to confuse the OS and actually
prevent it to mess with my disk.

-"two spaces","0","two spaces" = I have no idea.
-"30515 255 63" = this is the disk geometry setting specifying that
there are 30515 Cylinders, 255 Heads and 63 Sectors.
-"two spaces","26" = again, I'm clueless.

> You will depend on me to make another batch file to make the partition
> visible to Windows 2000 again.

Unfortunately you are right: I do not have access to the information
necessary to do it myself.
In summary: I think the batch file will not exactly "hide the
partition", but it will replace the current mess with a brand new
hidden partition that spans all over the disk.
All in all you are suggesting me (again) to make a big jump "out of
the blue and into the black", I don't know what will be the detailed
effect of your batch (although I *think* I'm close to knowing) and I
don't know what is coming next in your plan.
You will forgive me if I decide to take my time and wait for
clarifications.
Obviously, for some reason of yours, you are providing un-rewarded
help and I do know I have no rights whatsoever. I do appreciate the
time you dedicate me and I'm just trying to get the most out of it.
Thanks again,
Sergio
Anonymous
a b G Storage
May 28, 2004 6:10:06 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:<2hn5m9Fet52hU4@uni-berlin.de>...
<snipping partitions puzlle>
> > In fact this may seem weird but I guess it can be explained: the
> > partition table is still right but windows thinks the disk to be smaller.
>
> The conclusion is still wrong.
> Obviously the drive itself isn't checked and the info is gathered from
> the OS or BIOS.

I did figure that out myself, but thanks anyway.

> Clearly the apps need to be updated to indicate whether
> the partition table is in error or that the BIOS or OS is.

This is a very good suggestion, let's hope that Svend will find the
will and time to implement it.

-----------------------
Sergio Graziosi
Neurobiology Sector
SISSA/ISAS Trieste
www.sissa.it/~graziosi
-----------------------
Anonymous
a b G Storage
May 28, 2004 6:34:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Svend Olaf Mikkelsen was caught by the Folkert one-liner bite and wrote in message news:<40b86422.4104068@dtext.news.tele.dk>...
> On Wed, 26 May 2004 23:15:56 +0200, "Folkert Rienstra"
> <see_reply-to@myweb.nl> wrote:
>
> >What, he doesn't respond to email, does he?
>
> The user (including you?) decides what to put in the newsgroup.

In fact I did not mail Svend at all.

> I wonder how large a percentage of the 2000/XP 128 GB problems we see
> here. One of 1000? 10.000? 100.000? It may be a major problem.

What strikes me is how much the issue seems to be underestimated. I
have my faults for not addressing it from the beginning, but it is
strange to notice how little fuzz is heard around on this topic. I
wonder how Average Joe might hear or learn something about it.

Cheers,
Sergio
Anonymous
a b G Storage
May 29, 2004 3:32:47 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Sergio Graziosi" <sgrazios@email.it> wrote in message news:f3ac2e67.0405280134.7ec246c9@posting.google.com...
> Svend Olaf Mikkelsen was caught by the Folkert one-liner bite and wrote in message news:<40b86422.4104068@dtext.news.tele.dk>...
> > On Wed, 26 May 2004 23:15:56 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
> >
> > > What, he doesn't respond to email, does he?
> >
> > The user (including you?) decides what to put in the newsgroup.
>
> In fact I did not mail Svend at all.

Oh, why not?

>
> > I wonder how large a percentage of the 2000/XP 128 GB problems we
> > see here. One of 1000? 10.000? 100.000? It may be a major problem.
>
> What strikes me is how much the issue seems to be underestimated.

> I have my faults for not addressing it from the beginning, but it is
> strange to notice how little fuzz is heard around on this topic.

Actually, a similar case was brought here that stopped less than a week ago.
Over 50 messages in the thread.

> I wonder how Average Joe might hear or learn something about it.

By just doing the minimum of research?


>
> Cheers,
> Sergio
Anonymous
a b G Storage
May 29, 2004 3:48:45 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Svend Olaf Mikkelsen" <svolaf@inet.uni2.dk> wrote in message news:40b86422.4104068@dtext.news.tele.dk...
> On Wed, 26 May 2004 23:15:56 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>
> >What, he doesn't respond to email, does he?
>
> The user (including you?) decides what to put in the newsgroup. The advan
> tage of the newsgroup is that we learn something about the 128 GB problem,

Do we?
You made a questionable comment the other day that I responded
to and what did you do? You disappeared again, as usual.
When something is about to be learned, you do the disappearing act again.

> and that it for anyone interested can be found by search afterwards.

Right, and one would be enough for that.
Modifying FindPart in such a way that it is clear what the problem is
should rid us of those "1000? 10.000? 100.000?" of identical messages
that we don't need.

>
> I wonder how large a percentage of the 2000/XP 128 GB problems we
> see here. One of 1000? 10.000? 100.000? It may be a major problem.
> --
> Svend Olaf
Anonymous
a b G Storage
May 29, 2004 11:45:44 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 28 May 2004 01:49:58 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>Ok, since the purpose of my posts here is also to let other people
>learn from my mistakes I am not afraid to ask for clarifications:
>Your documentation on www. partitionsupport.com is useful but way far
>from complete. IOW it does not allow me to understand what all the
>numbers mean. Please correct me as needed and possibly fill in the
>blanks. Let's go in order:
>-"findpart 2 0 1"= work on disk 2, from the MBR partition table, first
>entry,
>
>- "-" = dunno, "27" = set partition ID to 27 useful to hide the
>partition,
>
>-"two spaces" I wonder if that means something, "0 0 2" = set
>partition start to CHS 0,0,2. It appears that we are having a double
>protection: changing the ID (but you report that win2000 does not
>respect it) so we also report a false partition start 0,0,2 instead of
>0,1,1. I guess that this is enough to confuse the OS and actually
>prevent it to mess with my disk.
>
>-"two spaces","0","two spaces" = I have no idea.
>-"30515 255 63" = this is the disk geometry setting specifying that
>there are 30515 Cylinders, 255 Heads and 63 Sectors.
>-"two spaces","26" = again, I'm clueless.
>
>> You will depend on me to make another batch file to make the partition
>> visible to Windows 2000 again.
>
>Unfortunately you are right: I do not have access to the information
>necessary to do it myself.
>In summary: I think the batch file will not exactly "hide the
>partition", but it will replace the current mess with a brand new
>hidden partition that spans all over the disk.
>All in all you are suggesting me (again) to make a big jump "out of
>the blue and into the black", I don't know what will be the detailed
>effect of your batch (although I *think* I'm close to knowing) and I
>don't know what is coming next in your plan.
>You will forgive me if I decide to take my time and wait for
>clarifications.
>Obviously, for some reason of yours, you are providing un-rewarded
>help and I do know I have no rights whatsoever. I do appreciate the
>time you dedicate me and I'm just trying to get the most out of it.
>Thanks again,
>Sergio

The ID for an NTFS partition is hexadecimal 07. Normally 17 is used
for a hidden NTFS partition, but since I also suggest that the
beginning location of the partition is changed, 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.

The parameters are explained on the screen by typing:

set findpart=edit
findpart editpart /?
set findpart=

The "26" is a catch all version number. The correct version number can
be used. The number of spaces does not matter.

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).
--
Svend Olaf
http://www.partitionsupport.com/utilities.htm
Anonymous
a b G Storage
May 30, 2004 3:17:18 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Svend Olaf Mikkelsen" <svolaf@inet.uni2.dk> wrote in message news:40b8e688.4294373@dtext.news.tele.dk...
> On 28 May 2004 01:49:58 -0700, sgrazios@email.it (Sergio Graziosi) wrote:
>
[snip]
> The "26" is a catch all version number.
> The correct version number can be used.

Makes one wonder what the point of it is for using it at all.
Anonymous
a b G Storage
June 3, 2004 4:52:28 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:<2hpqi9FfqfpdU2@uni-berlin.de>...
> > In fact I did not mail Svend at all.
>
> Oh, why not?

You know it: to have the opinion of more than one single person.

> > What strikes me is how much the issue seems to be underestimated.
>
> > I have my faults for not addressing it from the beginning, but it is
> > strange to notice how little fuzz is heard around on this topic.
>
> Actually, a similar case was brought here that stopped less than a week ago.
> Over 50 messages in the thread.

Thanks for the hint. Honestly, I was scared out from that thread at
message 10 (google numbering) by lines such as:
/quote
> Also as example (first) convince Phoenix/Award
> not to report cylinders larger then 1023 (for another disk):

Oh? Why should I make an ass out of myself?
The info on how to use Int13-AH=48h is quite clear.
/unquote

Maybe you can figure out yourself why.
Anyway, the thread does get informative later on, thanks again.

> > I wonder how Average Joe might hear or learn something about it.
>
> By just doing the minimum of research?

That IS the point, by doing a "minimum research" you will learn that
you simply need XP or Win2000 with the latest SP, or an UATA 6
controller, or the IAA installed. In all its adventures my disk always
met at least two of these requirements, hence the 128/137 limit was
sorted out from the possible causes of trouble. Your help allowed me
to realize that the situation is way more complicated.

--
Sergio
Anonymous
a b G Storage
June 3, 2004 11:27:37 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40b8e688.4294373@dtext.news.tele.dk>...
> 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
Anonymous
a b G Storage
June 5, 2004 1:22:04 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 3 Jun 2004 07:27:37 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>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
Anonymous
a b G Storage
June 5, 2004 1:38:28 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Fri, 04 Jun 2004 21:22:04 GMT, svolaf@inet.uni2.dk (Svend Olaf
Mikkelsen) wrote:

>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.
--
Svend Olaf
Anonymous
a b G Storage
June 7, 2004 5:21:53 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40c3e7f6.55299586@dtext.news.tele.dk>...
>
> 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
Anonymous
a b G Storage
June 7, 2004 1:57:41 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 7 Jun 2004 01:21:53 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>> 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

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
Anonymous
a b G Storage
June 9, 2004 1:36:55 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On Mon, 07 Jun 2004 09:57:41 GMT, svolaf@inet.uni2.dk (Svend Olaf
Mikkelsen) wrote:

>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
Anonymous
a b G Storage
June 9, 2004 11:00:09 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 3 Jun 2004 07:27:37 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>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.
--
Svend Olaf
Anonymous
a b G Storage
June 10, 2004 10:15:38 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40c75d89.18519508@dtext.news.tele.dk>...
> 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
Anonymous
a b G Storage
June 10, 2004 8:22:05 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

On 10 Jun 2004 06:15:38 -0700, sgrazios@email.it (Sergio Graziosi)
wrote:

>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.
--
Svend Olaf
Anonymous
a b G Storage
June 14, 2004 4:52:17 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote in message news:<40c8832a.8771582@dtext.news.tele.dk>...
> 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
-----------------------
!