screwed up partition and data recovery

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
-----------------------
29 answers Last reply
More about screwed partition data recovery
  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
    -----------------------
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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.
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
    -----------------------
Ask a new question

Read More

Data Recovery Controller Partition Storage