Sign in with
Sign up | Sign in
Your question

Partitions disappeared

Tags:
Last response: in Storage
Share
Anonymous
a b G Storage
March 11, 2005 11:09:36 PM

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

I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
One is about 10 gigs and holds the operating system. Yesterday the other
two partitions disappered while windows was running. So far I have rebooted
a couple of times (before i realized what was going on) and attempted to fix
the mbr with "FDISK /MBR" which did not fix the problem. I have run
FindPart and will include the ouput from that below. But after this point I
am out of my league. Is the output from FindPart enough to restore the
partitions? I am not concerned with the data on the OS partition. I am
fine with having to reinstall the OS. It's the data on the other 2 drives
that I am interested in. Can someone please guide me through this?

Thank you very much.

FindPart Output....................

Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
13317 0 33 Second FAT not found.

Partitions according to partition tables on first harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK

No signature CHS: 1216 0 1

More about : partitions disappeared

Anonymous
a b G Storage
March 12, 2005 11:59:12 AM

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

"Annika K" <none@none.com> wrote in message
news:o pGdndxdBKruwK_fRVn-vQ@comcast.com...
> I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
> One is about 10 gigs and holds the operating system. Yesterday the other
> two partitions disappered while windows was running. So far I have
rebooted
> a couple of times (before i realized what was going on) and attempted to
fix
> the mbr with "FDISK /MBR" which did not fix the problem. I have run
> FindPart and will include the ouput from that below. But after this point
I
> am out of my league. Is the output from FindPart enough to restore the
> partitions? I am not concerned with the data on the OS partition. I am
> fine with having to reinstall the OS. It's the data on the other 2 drives
> that I am interested in. Can someone please guide me through this?
>
> Thank you very much.
>
> FindPart Output....................
>
> Findpart, version 4.42.
> Copyright Svend Olaf Mikkelsen, 1999-2004.
>
> OS: DOS 7.10
>
> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
>
> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> 13317 0 33 Second FAT not found.
>
> Partitions according to partition tables on first harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
>
> No signature CHS: 1216 0 1
>
>

You did not indicate the size of the missing 2 partitions. Your mistake was
running fdisk /mbr as win98's fdisk only "understands" up to 64GB size
partitions. After that, you get cylinder wrap. An updated version of fdisk
from MS does up to 128GB.
Anonymous
a b G Storage
March 12, 2005 11:59:13 AM

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

"Lil' Dave" <spamyourself@virus.net> wrote in message
news:AbyYd.1583$qW.938@newsread3.news.atl.earthlink.net...
>
> You did not indicate the size of the missing 2 partitions. Your mistake was
> running fdisk /mbr as win98's fdisk only "understands" up to 64GB size
> partitions. After that, you get cylinder wrap. An updated version of fdisk
> from MS does up to 128GB.
>
Fdisk /mbr never fixes such problems. The original version works, it just
reports the wrong drive size.

If the OP has an older machine, the BIOS does not support over 135GB. You will
certainly get corruption with a 200GB disk and Win98.
Related resources
Anonymous
a b G Storage
March 12, 2005 12:27:45 PM

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

Is it too late to use the updated fdisk?

"Lil' Dave" <spamyourself@virus.net> wrote in message
news:AbyYd.1583$qW.938@newsread3.news.atl.earthlink.net...
> "Annika K" <none@none.com> wrote in message
> news:o pGdndxdBKruwK_fRVn-vQ@comcast.com...
>> I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the
>> HD.
>> One is about 10 gigs and holds the operating system. Yesterday the other
>> two partitions disappered while windows was running. So far I have
> rebooted
>> a couple of times (before i realized what was going on) and attempted to
> fix
>> the mbr with "FDISK /MBR" which did not fix the problem. I have run
>> FindPart and will include the ouput from that below. But after this
>> point
> I
>> am out of my league. Is the output from FindPart enough to restore the
>> partitions? I am not concerned with the data on the OS partition. I am
>> fine with having to reinstall the OS. It's the data on the other 2
>> drives
>> that I am interested in. Can someone please guide me through this?
>>
>> Thank you very much.
>>
>> FindPart Output....................
>>
>> Findpart, version 4.42.
>> Copyright Svend Olaf Mikkelsen, 1999-2004.
>>
>> OS: DOS 7.10
>>
>> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>>
>> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
>> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
>> 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
>>
>> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
>> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
>> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
>> 13317 0 33 Second FAT not found.
>>
>> Partitions according to partition tables on first harddisk:
>>
>> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
>> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
>> 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
>>
>> No signature CHS: 1216 0 1
>>
>>
>
> You did not indicate the size of the missing 2 partitions. Your mistake
> was
> running fdisk /mbr as win98's fdisk only "understands" up to 64GB size
> partitions. After that, you get cylinder wrap. An updated version of
> fdisk
> from MS does up to 128GB.
>
>
Anonymous
a b G Storage
March 12, 2005 1:21:22 PM

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

It's not an older machine..at least I don’t think so. The BIOS recognized
the hard drive correctly. How old is older? At any rate, is there any hope
for me or is all lost since I ran FDISK /mbr? If there is hope can someone
walk me through this or point to a site that tells me precisely how to
recover the partitions? I'm in over my head on this one.

Thanks very much

"Eric Gisin" <ericgisin@hotmail.com> wrote in message
news:D 0v6rl1o99@enews1.newsguy.com...
> "Lil' Dave" <spamyourself@virus.net> wrote in message
> news:AbyYd.1583$qW.938@newsread3.news.atl.earthlink.net...
>>
>> You did not indicate the size of the missing 2 partitions. Your mistake
>> was
>> running fdisk /mbr as win98's fdisk only "understands" up to 64GB size
>> partitions. After that, you get cylinder wrap. An updated version of
>> fdisk
>> from MS does up to 128GB.
>>
> Fdisk /mbr never fixes such problems. The original version works, it just
> reports the wrong drive size.
>
> If the OP has an older machine, the BIOS does not support over 135GB. You
> will
> certainly get corruption with a 200GB disk and Win98.
>
Anonymous
a b G Storage
March 12, 2005 3:56:10 PM

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

"Lil' Dave" <spamyourself@virus.net> wrote in message news:AbyYd.1583$qW.938@newsread3.news.atl.earthlink.net
> "Annika K" <none@none.com> wrote in message
> news:o pGdndxdBKruwK_fRVn-vQ@comcast.com...
> > I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
> > One is about 10 gigs and holds the operating system. Yesterday the other
> > two partitions disappered while windows was running. So far I have rebooted
> > a couple of times (before i realized what was going on) and attempted to fix
> > the mbr with "FDISK /MBR" which did not fix the problem. I have run
> > FindPart and will include the ouput from that below. But after this point I
> > am out of my league. Is the output from FindPart enough to restore the
> > partitions? I am not concerned with the data on the OS partition. I am
> > fine with having to reinstall the OS. It's the data on the other 2 drives
> > that I am interested in. Can someone please guide me through this?
> >
> > Thank you very much.
> >
> > FindPart Output....................
> >
> > Findpart, version 4.42.
> > Copyright Svend Olaf Mikkelsen, 1999-2004.
> >
> > OS: DOS 7.10
> >
> > Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
> >
> > --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> > 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> > 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
> >
> > ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> > 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> > 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> > 13317 0 33 Second FAT not found.
> >
> > Partitions according to partition tables on first harddisk:
> >
> > --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> > 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
> >
> > No signature CHS: 1216 0 1
> >
> >
>
> You did not indicate the size of the missing 2 partitions. Your mistake was
> running fdisk /mbr as win98's fdisk only "understands" up to 64GB size
> partitions. After that, you get cylinder wrap. An updated version of fdisk
> from MS does up to 128GB.

Wotanidiot.
Anonymous
a b G Storage
March 12, 2005 10:57:25 PM

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

"Annika K" <none@none.com> wrote in message news:o pGdndxdBKruwK_fRVn-vQ@comcast.com
> I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
> One is about 10 gigs and holds the operating system. Yesterday the other
> two partitions disappered while windows was running. So far I have rebooted
> a couple of times (before i realized what was going on) and attempted to fix
> the mbr with "FDISK /MBR" which did not fix the problem.

That only fixes (very limited) bootproblems.

> I have run FindPart and will include the ouput from that below.
> But after this point I am out of my league.

> Is the output from FindPart enough to restore the partitions?

It can usually be used to serve as input to a partition table editor.

> I am not concerned with the data on the OS partition. I am
> fine with having to reinstall the OS. It's the data on the other 2 drives
> that I am interested in. Can someone please guide me through this?
>
> Thank you very much.
>
> FindPart Output....................
>
> Findpart, version 4.42.
> Copyright Svend Olaf Mikkelsen, 1999-2004.
>
> OS: DOS 7.10
>
> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS

> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK

The bootrecord of the primary partition, drive C:

> 8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK

The bootrecord of the second logical, drive E:
The bootrecord of the first logical, (drive D:)  at cyl. 1216 is missing

>
> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454

FAT of the primary partition, drive C:

> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808

FATs of 2nd logical again.
The FATs of 1st logical at cyl 1216 are missing.

> 13317 0 33 Second FAT not found.
>
> Partitions according to partition tables on first harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS

> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK

MBR, primary partition, drive C:

> 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK

Extended partition, holder of logicals D: and E:
The EMBR at cyl. 1216 that the Extended partition points to and it's Logical
and the pointer to the second EMBR at cyl. 8511 and its logical are missing.

The EMBR at cyl. 8511 itself may be OK.

>
> No signature (at) CHS: 1216 0 1

May be the reason why the 1st EMBR isn't listed.
Inconclusive since there is no such comment on the second EMBR and it isn't
listed either.

Recreating the first EMBR may return access to drive E:
Drive D: is lost.
Anonymous
a b G Storage
March 12, 2005 10:57:26 PM

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

Thank you, Folkert. Do I use ptedit to recreate the EMBR? I read
instructions on this page
http://www.warpdoctor.org/walter/articles/2000/aa061400...
that say to change the type column from 0F to 05. Is this what i need to
do?

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:39hl1fF62hpi8U1@individual.net...

> Recreating the first EMBR may return access to drive E:
> Drive D: is lost.
March 13, 2005 4:31:29 AM

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

"Annika K" <none@none.com> wrote in message
news:o pGdndxdBKruwK_fRVn-vQ@comcast.com...
> I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
> One is about 10 gigs and holds the operating system. Yesterday the other
> two partitions disappered while windows was running. So far I have
rebooted
> a couple of times (before i realized what was going on) and attempted to
fix
> the mbr with "FDISK /MBR" which did not fix the problem. I have run
> FindPart and will include the ouput from that below. But after this point
I
> am out of my league. Is the output from FindPart enough to restore the
> partitions? I am not concerned with the data on the OS partition. I am
> fine with having to reinstall the OS. It's the data on the other 2 drives
> that I am interested in. Can someone please guide me through this?
>

Hi,

If Svend doesn't reply you may want to try DiskPatch from
www.diydatarecovery.nl

--
Joep
Anonymous
a b G Storage
March 14, 2005 12:10:07 AM

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

"Annika K" <none@none.com> wrote in message news:SpidnQdszJJyOa7fRVn-hA@comcast.com
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39hl1fF62hpi8U1@individual.net...
>
> > Recreating the first EMBR may return access to drive E:
> > Drive D: is lost.

> Thank you, Folkert. Do I use ptedit to recreate the EMBR?

That is what I prefer.

> I read instructions on this page
> http://www.warpdoctor.org/walter/articles/2000/aa061400...
> that say to change the type column from 0F to 05.

> Is this what i need to do?

Possibly. I have no idea what that is about without further examination.

Lines copied from other post, for reference:

Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474

Partitions according to partition bootrecords on first harddisk:
--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK

Partitions according to partition tables on first harddisk:
--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK

Punch the EMBR (extended partition MBR) button in the opening screen and
put most of the info of this line:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK

into line 2 of the new tables presented, like so:

type: 0F starting*: 8511 0 1, ending*: 24791 254 63, sectors before: xxxxxxxxx, sectors: 261554202,
where xxxxxxxxx = (8510+1)*(254+1)*63 = 136729215 (Cylinders and heads are 0-based)
* Starting and ending CHS will not be accepted for cylinders over 1023, you can fill
in the maximum CHS that is allowed for them: 1023 254 63, i.e. large drive placeholders.

If all is well then ptedit should now let you go to the next EMBR for the just defined
(2nd) extended partition and show you the logical (E:)  in it, as represented by:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK

and you should be able to open the bootrecord.

Next:
You can combine the info of these 2 lines to recreate the *first* line
(for the logical (D:)  drive in this first Extended partition ):

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK
8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK

like so:
type: 0B, starting*: 1216 1 1, ending*: 8510 254 63, sectors before: 63, sectors: xxxxxxxxx,
where xxxxxxxxx = ((8511-1216)*255*63)-63 = 117194112
And with the same proviso for starting and ending CHS as before.

This will now be the D: logical but the bootrecord is likely toast.

If you can recreate your partition with same size on an other drive
and format it you could copy the bootrecord parameters from there
and input them here and see what gives. It could be that that may
give other apps like WinHEX enough to recognize directories and
such (if still there) and perhaps let you copy files and/or directories.


Another side note (to help better understand what we are doing above):

With microsoft there are usually 2 partitions: 1 primary, one extended.
You can see an extended partition as an description of "the rest".
Each extended can have another primary and another extended, which in
turn has .... and so on and so on. The last extended only has the last primary.
The primaries in the extendeds we call logicals.

The description of the extended partition serves as a link and the "sectors
before" are referenced against the start of the physical drive (sector 0).
"Sectors" are the remaining sectors on the physical drive.
Primaries are referenced logically against the start of the extended
partition (the EMBR), usually a track distance so usually 63 sectors.
"Sectors" here is the size of the logical drive.
Anonymous
a b G Storage
March 14, 2005 12:10:08 AM

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

Here is my plan of attack...Please look it over and correct any
misunderstandings that I may have...

First of all, here is the First PTEdit screen before I make any changes....

Starting Ending Sectors
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
------------------------------------------------------------------
0C 80 0 1 1 191 254 63 63 19534977
0F 00 192 0 1 215 254 63 19535040 378748440

Then, after I click Goto EPBR the screen looks like this (before
modification)...

Starting Ending Sectors
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
------------------------------------------------------------------
FF 10 414 171 13 4 12 30 2565263962 1872013011
0D BC 737 20 54 586 155 24 715414953 2356450195
C1 9F 473 187 57 97 150 29 2960922799 89931260
51 33 158 72 17 302 240 1 886023102 2723627765

At this stage, I am supposed to change the second line so that the screen
looks like this...

Starting Ending Sectors
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
--------------------------------------------------------------------
FF 10 414 171 13 4 12 30 2565263962 1872013011
0F BC 1023 254 63 1023 254 63 19535040 261554202
C1 9F 473 187 57 97 150 29 2960922799 89931260
51 33 158 72 17 302 240 1 886023102 2723627765

....using CHS 1023,245,63 instead of the actual values because the cylinder
is over 1023 (is that correct? I'm unsure on this) and following Joep's
suggestions to use Type: 0F and "Sectors Before":19535040 (What about the
boot field? do I leave that BC?)

Then I click "Save Changes"
Then I click "Goto EPBR" for the 2nd line (the one i just modified)
Then I change the first line of the resulting screen to look like this

Starting Ending Sectors
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
--------------------------------------------------------------------
0B ?? 1023 254 63 1023 254 63 63 117194112

Again using CHS 1023,254,63 (What about the boot field here?)

Then I click Save changes and exit the program
Then i try booting the machine? I'm afraid

Thanks very much for your time in this matter.
Anonymous
a b G Storage
March 14, 2005 9:42:30 AM

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

Hi... If you had installed Windows 98 on this HD you should be able to
see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\ these are
hidden system files. Send me these two files and I will send you your
original Partition table along with a restoration utility developed by
me.

Best regards
Tanmoy Banerjee

Annika K wrote:
> I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on
the HD.
> One is about 10 gigs and holds the operating system. Yesterday the
other
> two partitions disappered while windows was running. So far I have
rebooted
> a couple of times (before i realized what was going on) and attempted
to fix
> the mbr with "FDISK /MBR" which did not fix the problem. I have run
> FindPart and will include the ouput from that below. But after this
point I
> am out of my league. Is the output from FindPart enough to restore
the
> partitions? I am not concerned with the data on the OS partition. I
am
> fine with having to reinstall the OS. It's the data on the other 2
drives
> that I am interested in. Can someone please guide me through this?
>
> Thank you very much.
>
> FindPart Output....................
>
> Findpart, version 4.42.
> Copyright Svend Olaf Mikkelsen, 1999-2004.
>
> OS: DOS 7.10
>
> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
>
> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> 13317 0 33 Second FAT not found.
>
> Partitions according to partition tables on first harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
>
> No signature CHS: 1216 0 1
Anonymous
a b G Storage
March 14, 2005 10:37:07 AM

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

"Annika K" <none@none.com> wrote in message news:cKednaSILMz1RKnfRVn-tQ@comcast.com
> Here is my plan of attack...Please look it over and correct any misunderstandings
> that I may have...
>
> First of all, here is the First PTEdit screen before I make any changes....
>
> Starting Ending Sectors
> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> ------------------------------------------------------------------
> 0C 80 0 1 1 191 254 63 63 19,534,977
> 0F 00 192 0 1 215 254 63 19535040 378,748,440

Hmm.

" > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK "
" > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK "

Findpart seems to have a mind of it's own. Svend should look into that.

>
> Then, after I click Goto EPBR the screen looks like this (before modification)...
>
> Starting Ending Sectors
> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> ------------------------------------------------------------------
> FF 10 414 171 13 4 12 30 2565263962 1872013011
> 0D BC 737 20 54 586 155 24 715414953 2356450195
> C1 9F 473 187 57 97 150 29 2960922799 89931260
> 51 33 158 72 17 302 240 1 886023102 2723627765
>
> At this stage, I am supposed to change the second line so that the screen
> looks like this...
>
> Starting Ending Sectors
> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> --------------------------------------------------------------------
> FF 10 414 171 13 4 12 0 2565263962 1872013011
> 0F BC 1023 254 63 1023 254 63 19535040 261554202
> C1 9F 473 187 57 97 150 29 2960922799 89931260
> 51 33 158 72 17 302 240 1 886023102 2723627765

You can clear lines 3 and 4 if you want.

>
> ...using CHS 1023,245,63 instead of the actual values because the cylinder
> is over 1023

> (is that correct? I'm unsure on this)

Yes, that is correct. The "actual" values aren't really actual, they are con-
verted/recalculated (but invalid) CHS representations of the LBA values.
They don't actually exist and can't be actually used in bios or driver
routines because CHS doesn't exist beyond 8GB (1024*256*63*512).

> and following Joep's suggestions to use Type: 0F and "Sectors Before":19535040

No, it should be my original value (136729215) but minus that 19535040 of the
first original primary which makes 117194175.

> (What about the boot field? do I leave that BC?)

You may clear that.

>
> Then I click "Save Changes"
> Then I click "Goto EPBR" for the 2nd line (the one i just modified)

You don't have to, you just check that you can and then you return, or you can leave it.
And you don't have to position the cursor, Goto EPBR just goes to the next
EPBR in the chain, like Goto Parent will return you to the previous one.

> Then I change the first line of the resulting screen to look like this

No, you return (Goto Parent) if you *did* go to the next EPBR to check if it's working.
As I said, the 3rd logical should be OK so you are not going to change anything there.
We will change the first line in the same screen where we changed that second line.

>
> Starting Ending Sectors
> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> --------------------------------------------------------------------
> 0B ?? 1023 254 63 1023 254 63 63 117194112
>
> Again using CHS 1023,254,63 (What about the boot field here?)

You may clear it.
You may also clear any unused lines that have rubbish in them.

>
> Then I click Save changes and exit the program
> Then i try booting the machine? I'm afraid
>
> Thanks very much for your time in this matter.

And it is taking more time than I expected it would. I must try and remember
how tricky it is and how easy you can make a mistake if you can't dry run it.
It's probably easier if you draw the screens on paper and check the
columns against each other than to try keeping it all in ones head.
Your constant removal of previous quotation doesn't make the process any
snappier either.
Anonymous
a b G Storage
March 14, 2005 10:39:00 AM

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

Time for another "oops".

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39jl2lF61mflsU1@individual.net
> "Annika K" <none@none.com> wrote in message news:SpidnQdszJJyOa7fRVn-hA@comcast.com
> > "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39hl1fF62hpi8U1@individual.net...
> >
> > > Recreating the first EMBR may return access to drive E:
> > > Drive D: is lost.
>
> > Thank you, Folkert. Do I use ptedit to recreate the EPBR?
>
> That is what I prefer.
>
> > I read instructions on this page
> > http://www.warpdoctor.org/walter/articles/2000/aa061400...
> > that say to change the type column from 0F to 05.
>
> > Is this what i need to do?
>
> Possibly. I have no idea what that is about without further examination.
>
> Lines copied from other post, for reference:
>
> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
> Partitions according to partition bootrecords on first harddisk:
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> 8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK
>
> Partitions according to partition tables on first harddisk:
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK
>
> Punch the EPBR (Extended Partition mBR) button in the opening screen and
> put most of the info of this line:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK
>
> into line 2 of the new tables presented, like so:
>
> type: 0F starting*: 8511 0 1, ending*: 24791 254 63, sectors before: xxxxxxxxx, sectors: 261554202,

> where xxxxxxxxx = (8510+1)*(254+1)*63 = 136729215 (Cylinders and heads are 0-based)

So with the correction below in mind we have to correct for the space taken up by the primary partition:
136729215-19535040 = 117194175

> * Starting and ending CHS will not be accepted for cylinders over 1023, you can fill
> in the maximum CHS that is allowed for them: 1023 254 63, i.e. large drive placeholders.
>
> If all is well then ptedit should now let you go to the next EPBR for the just defined
> (2nd) extended partition and show you the logical (E:)  in it, as represented by:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK
>
> and you should be able to open the bootrecord.
>
> Next:
> You can combine the info of these 2 lines to recreate the *first* line
> (for the logical (D:)  drive in this first Extended partition ):
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK
> 8511 1 0B 63 261554202 127712 8511 1 1 24791 254 63 OK OK
>
> like so:
> type: 0B, starting*: 1216 1 1, ending*: 8510 254 63, sectors before: 63, sectors: xxxxxxxxx,
> where xxxxxxxxx = ((8511-1216)*255*63)-63 = 117194112
> And with the same proviso for starting and ending CHS as before.
>
> This will now be the D: logical but the bootrecord is likely toast.
>
> If you can recreate your partition with same size on an other drive
> and format it you could copy the bootrecord parameters from there
> and input them here and see what gives. It could be that that may
> give other apps like WinHEX enough to recognize directories and
> such (if still there) and perhaps let you copy files and/or directories.
>
>
> Another side note (to help better understand what we are doing above):
>
> With microsoft there are usually 2 partitions: 1 primary, one extended.
> You can see an extended partition as a description of "the rest".
> Each extended can have another primary and another extended, which in
> turn has .... and so on and so on. The last extended only has the last primary.
> The primaries in the extendeds we call logicals.
>
> The description of the extended partition serves as a link and the "sectors
> before" are referenced against the start of the physical drive (sector 0).

Oops, that's wrong, It's relative to a single point, but it is not sector 0.
It's relative to the start of the original extended partition, the disk address
of the first EPBR.

> "Sectors" are the remaining sectors on the physical drive.

> Primaries are referenced logically against the start of the extended
> partition (the EPBR), usually a track distance so usually 63 sectors.
> "Sectors" here is the size of the logical drive.
March 14, 2005 4:57:13 PM

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

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:39kq20F61udc5U2@individual.net...
>
> And it is taking more time than I expected it would. I must try and
remember
> how tricky it is and how easy you can make a mistake if you can't dry run
it.
> It's probably easier if you draw the screens on paper and check the
> columns against each other than to try keeping it all in ones head.
> Your constant removal of previous quotation doesn't make the process any
> snappier either.

Not trying to be a smart-ass (it's hard) I'd like to make one suggestion:

Re-type your instructions from scratch so there's one nicely formatted email
with only correct values.

--
Joepie
March 14, 2005 7:32:15 PM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message
news:1110811350.377546.165830@o13g2000cwo.googlegroups.com...
> Hi... If you had installed Windows 98 on this HD you should be able to
> see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\

Ah! in the rott! Splendid! And isn't that SUHDLOG.DAT?

> these are
> hidden system files. Send me these two files and I will send you your
> original Partition table

Partition locations are already known. Read the rest of the thread.

--
Joepie
Anonymous
a b G Storage
March 15, 2005 1:02:59 AM

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

I suggest you use partition table doctor.It provides very useful
functions: Backup partition table, Restore partition table, Rebuild
partition table, undelete partition,Fixboot.
use rebuild partition table function,it can automatic find out harddisk
partition!
see more:http://www.ptdd.com
Anonymous
a b G Storage
March 15, 2005 3:13:51 AM

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

"Joep" <available@request.nl> wrote in message news:D 5938$42358b61$3eddca68$5823@nf1.news-service.com
> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39kq20F61udc5U2@individual.net...
> >
> > And it is taking more time than I expected it would. I must try and remember
> > how tricky it is and how easy you can make a mistake if you can't dry run it.
> > It's probably easier if you draw the screens on paper and check the
> > columns against each other than to try keeping it all in ones head.
> > Your constant removal of previous quotation doesn't make the process any
> > snappier either.
>
> Not trying to be a smart-ass (it's hard)

And failing.

> I'd like to make one suggestion:
>
> Re-type your instructions from scratch so there's one nicely formatted email
> with only correct values.

Well, what holds you back to do that yourself and take the credit?
Anonymous
a b G Storage
March 15, 2005 4:13:53 AM

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

That was a typographical mistake. I guess everyone could make out its
not rott but root. Regarding the issue of Partition locations, agreed
its known but how does a layman restore it? assuming he/she does not
know how to edit physical sectors manually. Moreover the structrure of
Boot Record is not known, so I asked for the SUHDLOG.DAT file.

Joep wrote:
> "Tanmoy" <datarecovery@hotpop.com> wrote in message
> news:1110811350.377546.165830@o13g2000cwo.googlegroups.com...
> > Hi... If you had installed Windows 98 on this HD you should be able
to
> > see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\
>
> Ah! in the rott! Splendid! And isn't that SUHDLOG.DAT?

that was a typographical mistake. I guess everyone could make out its
not rott but root.
>
> > these are
> > hidden system files. Send me these two files and I will send you
your
> > original Partition table
>
> Partition locations are already known. Read the rest of the thread.

Regarding the issue of Partition location, agreed its known but how
does a layman restore it? assuming he/she does not know how to edit
physical sectors manually. Moreover the structrure of Boot Record is
not known, so I asked for the SUHDLOG.DAT file

> --
> Joepie
March 15, 2005 12:55:17 PM

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

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:39ms0vF6291kuU1@individual.net...
> "Joep" <available@request.nl> wrote in message
news:D 5938$42358b61$3eddca68$5823@nf1.news-service.com
> > "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:39kq20F61udc5U2@individual.net...
> > >
> > > And it is taking more time than I expected it would. I must try and
remember
> > > how tricky it is and how easy you can make a mistake if you can't dry
run it.
> > > It's probably easier if you draw the screens on paper and check the
> > > columns against each other than to try keeping it all in ones head.
> > > Your constant removal of previous quotation doesn't make the process
any
> > > snappier either.
> >
> > Not trying to be a smart-ass (it's hard)
>
> And failing.

lol. dumb-ass!

>
> > I'd like to make one suggestion:
> >
> > Re-type your instructions from scratch so there's one nicely formatted
email
> > with only correct values.
>
> Well, what holds you back to do that yourself and take the credit?

Hahaha! do it yourself Volkert!

--
Joepie
Anonymous
a b G Storage
March 15, 2005 7:04:20 PM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message news:1110878033.904879.271150@f14g2000cwb.googlegroups.com
> That was a typographical mistake.

No, that were several. One would be an unfortunate mistake but
several gives insight in how much you can be trusted with ones data
if you can't even be bothered to check your posts before sending.

> I guess everyone could make out its not rott but root.
> Regarding the issue of Partition locations, agreed
> its known but how does a layman restore it? assuming he/she does not
> know how to edit physical sectors manually.

Not only can you barely write, you don't read very well either, don't
you, "Tanmoy". Who said anything about editing "physical sectors".

> Moreover the structrure of Boot Record is not known, so I asked
> for the SUHDLOG.DAT file.

Oh, and my SUHDLOG.DAT is 3 years old. I have had several HDs
since then and I'm 100% certain that my current one (36GB) is par-
titioned differently from when I originally installed on a 4 GB one.
I would most certainly destroy my system if I followed your advice.

>
> Joep wrote:
> > "Tanmoy" datarecovery@hotpop.com> wrote in message news:1110811350.377546.165830@o13g2000cwo.googlegroups.com...
> > > Hi... If you had installed Windows 98 on this HD you should be able to
> > > see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\
> >
> > Ah! in the rott! Splendid! And isn't that SUHDLOG.DAT?
>
> that was a typographical mistake. I guess everyone could make out its
> not rott but root.
> >
> > > these are
> > > hidden system files. Send me these two files and I will send you your
> > > original Partition table
> >
> > Partition locations are already known. Read the rest of the thread.
>
> Regarding the issue of Partition location, agreed its known but how
> does a layman restore it? assuming he/she does not know how to edit
> physical sectors manually. Moreover the structrure of Boot Record is
> not known, so I asked for the SUHDLOG.DAT file
>
> > --
> > Joepie
March 15, 2005 9:59:39 PM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message
news:1110878033.904879.271150@f14g2000cwb.googlegroups.com...
> That was a typographical mistake. I guess everyone could make out its
> not rott but root. Regarding the issue of Partition locations, agreed
> its known but how does a layman restore it? assuming he/she does not
> know how to edit physical sectors manually. Moreover the structrure of
> Boot Record is not known, so I asked for the SUHDLOG.DAT file.
>

Hi.

Yes, you are right, it's just, we see here (this thread) a living example of
what could happen if you're not exact and to the point with the instructions
you give. And in that light, not even getting a simple thing as a filename
right doesn't add to the confidence. Yes indeed the bootrecord appears to be
lost, and I very much doubt if that's the only component that's damaged; the
partition table EPBR was trashed, the boot sector as well, no FAT was found
so part of the first FAT at least is damaged as well. And because of that I
doubt if knowing what the boot sector looked like will do much good. If this
were up to me, I'd try the recover the last logical and recover data from
the first logical partition using a file recovery tool. You could even
redefine the partition to make it a little easier on the tool of your
choice.

As far as I understand the files you refer to are created during setup. If
the partitioning changed since that there's not too much use for those
files. In fact data has been lost more than once because of those files and
the restoration of partition tables and boot sectors from those files.
Because of that I'd never rely on them. IMO it's better to scan a disk,
analyse the results of the scan, and plan and perform interventions based on
at analysis.

Does one know how to use the information as it is presented by Findpart?
Yes, that's the question. Either you know, or you don't. The latter seems to
be the case more frequently, and in those cases 99 out of 100 times Svend
has to come to the rescue. Svend recently indicated that he's slowing down a
bit, or has to slow down a bit, because there's so many requests for help
that he fears he may not be able to maintain the high quality of his
support. Svend has a reputation to keep up ;-). It is also because of this
reputation, so it seems, that people trust him blindly to resolve an issue,
or at least that he knows where and when to stop so it doesn't turn into a
bigger mess. I know what Svend is capable of (as anyone that visits this
group on a regular basis probably). If Svend created a batch file to fix my
disk I'd not have too much trouble running that. No offense intended, but
you I don't know, so that's a bit more difficult. F'Nut (alias Folkert) I do
know and I'd never let him touch my disk, before you know it, you have 'free
space partitions' (don't ask me, only he knows) all over the place.

Anyway ... There are tools available that are able to resolve many of the
issues that can be resolved with the help of Findpart and Svend in a safe
manner. Tools that allow about ordinary users to solve issues even when they
don't know how to edit a disk and without indepth knowledge on partition
table and boot sector structures. Tools that only require the user to select
the correct disk and the partitions that need repair.

If people do not want to use those (often commercial) tools then they either
need to be patient or take some risks. I suggest they first clone the victim
disk or practice on a dummy disk.

--
Joep
http://www.diydatarecovery.nl
Anonymous
a b G Storage
March 15, 2005 10:09:34 PM

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

Thank you very much for your help. Using my "modified" plan of attack I was
able to restore the E: drive (and this is the one that was of most
importance to me). When I try to select the D: drive I get an error message
which reads "D:\ is not accessible. A device attached to the system is not
functioning." At this stage, do I give up on the data on that partition?
What other options are still available to me?

For those who are interested, here is what my PTEdit screen looked like in
the end...(I didn't bother removing the 3rd and 4th lines as that seemed
optional)

Starting Ending Sectors
Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
------------------------------------------------------------------
0B 1023 254 63 1023 254 63 63 117194112
05 1023 254 63 1023 254 63 117194175 261554202
C1 9F 473 187 57 97 150 29 2960922799 89931260
51 33 158 72 17 302 240 1 886023102 2723627765



"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:39kq20F61udc5U2@individual.net...
> "Annika K" <none@none.com> wrote in message
> news:cKednaSILMz1RKnfRVn-tQ@comcast.com
>> Here is my plan of attack...Please look it over and correct any
>> misunderstandings
>> that I may have...
>>
>> First of all, here is the First PTEdit screen before I make any
>> changes....
>>
>> Starting Ending Sectors
>> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
>> ------------------------------------------------------------------
>> 0C 80 0 1 1 191 254 63 63
>> 19,534,977
>> 0F 00 192 0 1 215 254 63 19535040
>> 378,748,440
>
> Hmm.
>
> " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK
> OK "
> " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63
> OK "
>
> Findpart seems to have a mind of it's own. Svend should look into that.
>
>>
>> Then, after I click Goto EPBR the screen looks like this (before
>> modification)...
>>
>> Starting Ending Sectors
>> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
>> ------------------------------------------------------------------
>> FF 10 414 171 13 4 12 30 2565263962
>> 1872013011
>> 0D BC 737 20 54 586 155 24 715414953
>> 2356450195
>> C1 9F 473 187 57 97 150 29 2960922799
>> 89931260
>> 51 33 158 72 17 302 240 1 886023102
>> 2723627765
>>
>> At this stage, I am supposed to change the second line so that the screen
>> looks like this...
>>
>> Starting Ending Sectors
>> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
>> --------------------------------------------------------------------
>> FF 10 414 171 13 4 12 0 2565263962
>> 1872013011
>> 0F BC 1023 254 63 1023 254 63 19535040
>> 261554202
>> C1 9F 473 187 57 97 150 29 2960922799
>> 89931260
>> 51 33 158 72 17 302 240 1 886023102
>> 2723627765
>
> You can clear lines 3 and 4 if you want.
>
>>
>> ...using CHS 1023,245,63 instead of the actual values because the
>> cylinder
>> is over 1023
>
>> (is that correct? I'm unsure on this)
>
> Yes, that is correct. The "actual" values aren't really actual, they are
> con-
> verted/recalculated (but invalid) CHS representations of the LBA values.
> They don't actually exist and can't be actually used in bios or driver
> routines because CHS doesn't exist beyond 8GB (1024*256*63*512).
>
>> and following Joep's suggestions to use Type: 0F and "Sectors
>> Before":19535040
>
> No, it should be my original value (136729215) but minus that 19535040 of
> the
> first original primary which makes 117194175.
>
>> (What about the boot field? do I leave that BC?)
>
> You may clear that.
>
>>
>> Then I click "Save Changes"
>> Then I click "Goto EPBR" for the 2nd line (the one i just modified)
>
> You don't have to, you just check that you can and then you return, or you
> can leave it.
> And you don't have to position the cursor, Goto EPBR just goes to the next
> EPBR in the chain, like Goto Parent will return you to the previous one.
>
>> Then I change the first line of the resulting screen to look like this
>
> No, you return (Goto Parent) if you *did* go to the next EPBR to check if
> it's working.
> As I said, the 3rd logical should be OK so you are not going to change
> anything there.
> We will change the first line in the same screen where we changed that
> second line.
>
>>
>> Starting Ending Sectors
>> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
>> --------------------------------------------------------------------
>> 0B ?? 1023 254 63 1023 254 63 63
>> 117194112
>>
>> Again using CHS 1023,254,63 (What about the boot field here?)
>
> You may clear it.
> You may also clear any unused lines that have rubbish in them.
>
>>
>> Then I click Save changes and exit the program
>> Then i try booting the machine? I'm afraid
>>
>> Thanks very much for your time in this matter.
>
> And it is taking more time than I expected it would. I must try and
> remember
> how tricky it is and how easy you can make a mistake if you can't dry run
> it.
> It's probably easier if you draw the screens on paper and check the
> columns against each other than to try keeping it all in ones head.
> Your constant removal of previous quotation doesn't make the process any
> snappier either.
Anonymous
a b G Storage
March 16, 2005 1:09:44 AM

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

Folkert Rienstra wrote:
> "Tanmoy" <datarecovery@hotpop.com> wrote in message
news:1110878033.904879.271150@f14g2000cwb.googlegroups.com
> > That was a typographical mistake.
>
> No, that were several. One would be an unfortunate mistake but
> several gives insight in how much you can be trusted with ones data
> if you can't even be bothered to check your posts before sending.
>
> > I guess everyone could make out its not rott but root.
> > Regarding the issue of Partition locations, agreed
> > its known but how does a layman restore it? assuming he/she does
not
> > know how to edit physical sectors manually.
>
> Not only can you barely write, you don't read very well either, don't

> you, "Tanmoy". Who said anything about editing "physical sectors".
>
> > Moreover the structrure of Boot Record is not known, so I asked
> > for the SUHDLOG.DAT file.
>
> Oh, and my SUHDLOG.DAT is 3 years old. I have had several HDs
> since then and I'm 100% certain that my current one (36GB) is par-
> titioned differently from when I originally installed on a 4 GB one.
> I would most certainly destroy my system if I followed your advice.

I guess its time you learn to read well too ! in my earlier post I said

if you had installed Windows 98 on this HD (and not cloned from another
drive OK). It doesnt matter if its 3 yrs old installation as long as
you did not change the partition structure.

I hope you would agree that what findpart or any other utility reports
is the present partition structure, and many virus do alter the
structure of the partition table. Till date I havent come across any
that alters SUHDLOG.DAT. (let me know if there is one whic alters
SUHDLOG.DAT)

If there is no partition alteration after installation of WIN98 and you
know to extract the partition and Boot Record out of SUHDLOG.DAT, I
doubt if there is any other better utilty to recreate the original
ones.

>
> >
> > Joep wrote:
> > > "Tanmoy" datarecovery@hotpop.com> wrote in message
news:1110811350.377546.165830@o13g2000cwo.googlegroups.com...
> > > > Hi... If you had installed Windows 98 on this HD you should be
able to
> > > > see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\
> > >
> > > Ah! in the rott! Splendid! And isn't that SUHDLOG.DAT?
> >
> > that was a typographical mistake. I guess everyone could make out
its
> > not rott but root.
> > >
> > > > these are
> > > > hidden system files. Send me these two files and I will send
you your
> > > > original Partition table
> > >
> > > Partition locations are already known. Read the rest of the
thread.
> >
> > Regarding the issue of Partition location, agreed its known but how
> > does a layman restore it? assuming he/she does not know how to edit
> > physical sectors manually. Moreover the structrure of Boot Record
is
> > not known, so I asked for the SUHDLOG.DAT file
> >
> > > --
> > > Joepie
Anonymous
a b G Storage
March 16, 2005 2:21:19 AM

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

I suggest you use partition table doctor.It provides very useful
functions: Backup partition table, Restore partition table, Rebuild
partition table, undelete partition,Fixboot.
see more:http://www.ptdd.com/recoverylostpartition.htm
Anonymous
a b G Storage
March 16, 2005 11:03:08 AM

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

"Annika K" <none@none.com> wrote in message news:CeednRYxHMb4CKrfRVn-ug@comcast.com
> Thank you very much for your help. Using my "modified" plan of attack I was
> able to restore the E: drive (and this is the one that was of most importance to me).

> When I try to select the D: drive I get an error message which reads
> "D:\ is not accessible.

As expected.

> A device attached to the system is not functioning."

The error that one gets is probably dependent on what the gar-
bage data in the partition's bootrecord is. Apparently the file
system thinks that it is formatted but it can't make sense of it.

> At this stage, do I give up on the data on that partition?
> What other options are still available to me?

I believe I gave you some hints. Maybe you should read them again?
Btw, WinHex is here: http://www.x-ways.net/winhex/index-m.html

>
> For those who are interested, here is what my PTEdit screen looked like in
> the end...

> (I didn't bother removing the 3rd and 4th lines as that seemed optional)

It may start to bother you if you keep running reports and they show up
in there each time and clutter up the report. If not, then who cares, right?

>
> Starting Ending Sectors
> Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> ------------------------------------------------------------------
> 0B 1023 254 63 1023 254 63 63 117194112
> 05 1023 254 63 1023 254 63 117194175 261554202
> C1 9F 473 187 57 97 150 29 2960922799 89931260
> 51 33 158 72 17 302 240 1 886023102 2723627765

You could re-run Findpart again although if Findpart does it's job cor-
rectly it is expected to still give the same info re the detected structures
(FAT and Bootrecord search), but you never know until you try it, right?
Maybe that that previously missing, now restored signature has some
influence on how Findpart conducts it's search.

The only differences to be expected are that the partiton tables now
should show show the re-added partitions and the EPBR signature OK.
And the 1023 254 63 entries will likely prompt Findpart to add extra
lines with the socalled 'actual' values (that aren't the actual values at all).

>

Please setup your newsreader properly. The below quotation is unreadable.

> "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39kq20F61udc5U2@individual.net...
> > "Annika K" none@none.com> wrote in message news:cKednaSILMz1RKnfRVn-tQ@comcast.com
> > > Here is my plan of attack...Please look it over and correct any
> > > misunderstandings
> > > that I may have...
> > >
> > > First of all, here is the First PTEdit screen before I make any
> > > changes....
> > >
> > > Starting Ending Sectors
> > > Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> > > ------------------------------------------------------------------
> > > 0C 80 0 1 1 191 254 63 63
> > > 19,534,977
> > > 0F 00 192 0 1 215 254 63 19535040
> > > 378,748,440
> >
> > Hmm.
> >
> > " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK
> > OK "
> > " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63
> > OK "
> >
> > Findpart seems to have a mind of it's own. Svend should look into that.
> >

[snip]
Anonymous
a b G Storage
March 16, 2005 6:33:46 PM

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

On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
>
> No, that were several. One would be an unfortunate mistake but
> several gives insight in how much you can be trusted with ones data
> if you can't even be bothered to check your posts before sending.


The pot called the kettle black.

It is "several give" not "several gives".
Your ellipsis leaves out "mistakes".

To leave off an 's' may be a typo but to add one is ignorance.


On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
>
> Not only can you barely write, you don't read very well either,
> don't you, "Tanmoy".


Double negatives can be used to give emphasis but here your double
negative is nonsense.
Anonymous
a b G Storage
March 16, 2005 10:02:29 PM

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

Thanks for your support. I feel this is a tech group and one should not
be too much bothered with minor grammatical mistakes. Everone would
agree that english is spoken and written in different ways in the
world. However there are guys who would like to deviate from the real
technical issue and say something else.

Mark M wrote:
> On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
> >
> > No, that were several. One would be an unfortunate mistake but
> > several gives insight in how much you can be trusted with ones data
> > if you can't even be bothered to check your posts before sending.
>
>
> The pot called the kettle black.
>
> It is "several give" not "several gives".
> Your ellipsis leaves out "mistakes".
>
> To leave off an 's' may be a typo but to add one is ignorance.
>
>
> On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
> >
> > Not only can you barely write, you don't read very well either,
> > don't you, "Tanmoy".
>
>
> Double negatives can be used to give emphasis but here your double
> negative is nonsense.
Anonymous
a b G Storage
March 17, 2005 3:28:51 AM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message news:1110953384.727768.36830@o13g2000cwo.googlegroups.com
> Folkert Rienstra wrote:
> > "Tanmoy" <datarecovery@hotpop.com> wrote in message news:1110878033.904879.271150@f14g2000cwb.googlegroups.com
> > > That was a typographical mistake.
> >
> > No, that were several. One would be an unfortunate mistake but
> > several gives insight in how much you can be trusted with ones data
> > if you can't even be bothered to check your posts before sending.
> >
> > > I guess everyone could make out its not rott but root.
> > > Regarding the issue of Partition locations, agreed
> > > its known but how does a layman restore it? assuming he/she does not
> > > know how to edit physical sectors manually.
> >
> > Not only can you barely write, you don't read very well either, don't
> > you, "Tanmoy". Who said anything about editing "physical sectors".
> >
> > > Moreover the structrure of Boot Record is not known, so I asked
> > > for the SUHDLOG.DAT file.
> >
> > Oh, and my SUHDLOG.DAT is 3 years old. I have had several HDs
> > since then and I'm 100% certain that my current one (36GB) is par-
> > titioned differently from when I originally installed on a 4 GB one.
> > I would most certainly destroy my system if I followed your advice.
>
> I guess its time you learn to read well too ! in my earlier post I said
>
> if you had installed Windows 98 on this HD

Of course I have Win98 installed on my drive, how else would I be able
to run it if it wasn't 'installed'. Doesn't mean that I actually performed
the installation procedure of Windows on this particular drive.

> (and not cloned from another drive OK).

Who said anything about cloning. Oh, and 'cloned' would actually
be alright, if not, it would not be a real clone, now wouldn't it.

> It doesnt matter if its 3 yrs old installation as long
> as you did not change the partition structure.

Right, that is what matters if you go that route, that the files actually
represent the current scheme.

>
> I hope you would agree that what findpart or any other utility reports
> is the present partition structure, and many virus do alter the
> structure of the partition table.

So what?
The FAT tables and partition bootrecords out of place would give
you immediate notice that something like that would have happened.
Did you even bother to try and find out what the Findpart report
is actually showing?

> Till date I havent come across any that alters SUHDLOG.DAT.
> (let me know if there is one whic alters SUHDLOG.DAT)
>
> If there is no partition alteration after installation of WIN98 and you
> know to extract the partition and Boot Record out of SUHDLOG.DAT,
> I doubt if there is any other better utilty to recreate the original ones.
>
> >
> > >
> > > Joep wrote:
> > > > "Tanmoy" datarecovery@hotpop.com> wrote in message news:1110811350.377546.165830@o13g2000cwo.googlegroups.com...
> > > > > Hi... If you had installed Windows 98 on this HD you should be able to
> > > > > see 2 files SUHODLOG.DAT and SUHODLOG.BAK in rott of C:\
> > > >
> > > > Ah! in the rott! Splendid! And isn't that SUHDLOG.DAT?
> > >
> > > that was a typographical mistake. I guess everyone could make out its
> > > not rott but root.
> > > >
> > > > > these are
> > > > > hidden system files. Send me these two files and I will send you your
> > > > > original Partition table
> > > >
> > > > Partition locations are already known. Read the rest of the thread.
> > >
> > > Regarding the issue of Partition location, agreed its known but how
> > > does a layman restore it? assuming he/she does not know how to edit
> > > physical sectors manually. Moreover the structrure of Boot Record is
> > > not known, so I asked for the SUHDLOG.DAT file
> > >
> > > > --
> > > > Joepie
March 17, 2005 12:32:18 PM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message
news:1111028549.209085.138470@z14g2000cwz.googlegroups.com...
> Thanks for your support. I feel this is a tech group and one should not
> be too much bothered with minor grammatical mistakes.

Yes, that is the easy way out. My post that apart from the typo addresses
the context of the typo plus the usability of sudhlog.dat you did not
answer:

"Tanmoy" <datarecovery@hotpop.com> wrote in message
news:1110878033.904879.271150@f14g2000cwb.googlegroups.com...
> That was a typographical mistake. I guess everyone could make out its
> not rott but root. Regarding the issue of Partition locations, agreed
> its known but how does a layman restore it? assuming he/she does not
> know how to edit physical sectors manually. Moreover the structrure of
> Boot Record is not known, so I asked for the SUHDLOG.DAT file.
>

Hi.

Yes, you are right, it's just, we see here (this thread) a living example of
what could happen if you're not exact and to the point with the instructions
you give. And in that light, not even getting a simple thing as a filename
right doesn't add to the confidence. Yes indeed the bootrecord appears to be
lost, and I very much doubt if that's the only component that's damaged; the
partition table EPBR was trashed, the boot sector as well, no FAT was found
so part of the first FAT at least is damaged as well. And because of that I
doubt if knowing what the boot sector looked like will do much good. If this
were up to me, I'd try the recover the last logical and recover data from
the first logical partition using a file recovery tool. You could even
redefine the partition to make it a little easier on the tool of your
choice.

As far as I understand the files you refer to are created during setup. If
the partitioning changed since that there's not too much use for those
files. In fact data has been lost more than once because of those files and
the restoration of partition tables and boot sectors from those files.
Because of that I'd never rely on them. IMO it's better to scan a disk,
analyse the results of the scan, and plan and perform interventions based on
at analysis.

Does one know how to use the information as it is presented by Findpart?
Yes, that's the question. Either you know, or you don't. The latter seems to
be the case more frequently, and in those cases 99 out of 100 times Svend
has to come to the rescue. Svend recently indicated that he's slowing down a
bit, or has to slow down a bit, because there's so many requests for help
that he fears he may not be able to maintain the high quality of his
support. Svend has a reputation to keep up ;-). It is also because of this
reputation, so it seems, that people trust him blindly to resolve an issue,
or at least that he knows where and when to stop so it doesn't turn into a
bigger mess. I know what Svend is capable of (as anyone that visits this
group on a regular basis probably). If Svend created a batch file to fix my
disk I'd not have too much trouble running that. No offense intended, but
you I don't know, so that's a bit more difficult. F'Nut (alias Folkert) I do
know and I'd never let him touch my disk, before you know it, you have 'free
space partitions' (don't ask me, only he knows) all over the place.

Anyway ... There are tools available that are able to resolve many of the
issues that can be resolved with the help of Findpart and Svend in a safe
manner. Tools that allow about ordinary users to solve issues even when they
don't know how to edit a disk and without indepth knowledge on partition
table and boot sector structures. Tools that only require the user to select
the correct disk and the partitions that need repair.

If people do not want to use those (often commercial) tools then they either
need to be patient or take some risks. I suggest they first clone the victim
disk or practice on a dummy disk.


--
Joep
Anonymous
a b G Storage
March 17, 2005 7:10:44 PM

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

"Tanmoy" <datarecovery@hotpop.com> wrote in message news:1111028549.209085.138470@z14g2000cwz.googlegroups.com...
> Thanks for your support.

And now we know in what ballpark you play.

> I feel this is a tech group and one should not be too
> much bothered with minor grammatical mistakes.

And yet that is exactly what your buddy Mark focussed on
and you thank him for it.

> Everone

Who is everone?

> would agree that english is spoken and written in different ways in
> the world.

And what has that got to do with typos?

> However there are guys who would like to deviate from the real
> technical issue and say something else.

Like you are doing now.

>
> Mark M wrote:
> > On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
> > >
> > > No, that were several. One would be an unfortunate mistake but
> > > several gives insight in how much you can be trusted with ones data
> > > if you can't even be bothered to check your posts before sending.
> >
> >
> > The pot called the kettle black.
> >
> > It is "several give" not "several gives".
> > Your ellipsis leaves out "mistakes".

And that's why it obviously became "gives", as in ... , that "gives" ...
It all depends on how you interpret what was "left out".

> >
> > To leave off an 's' may be a typo but to add one is ignorance.

Deliberately changing what was said to point out a possible mis-
take is malice by someone who apparently has an axe to grind.

> >
> >
> > On Tue 15 Mar 2005 15:04:20, Folkert Rienstra wrote:
> > >
> > > Not only can you barely write, you don't read very well either,
> > > don't you, "Tanmoy".
> >
> >
> > Double negatives can be used to give emphasis but here your double
> > negative is nonsense.
>
Anonymous
a b G Storage
March 18, 2005 7:09:25 PM

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

On Fri, 11 Mar 2005 20:09:36 -0700, "Annika K" <none@none.com> wrote:

>I am runing Windows 98 on a 200 Gig HD. There are 3 partitions on the HD.
>One is about 10 gigs and holds the operating system. Yesterday the other
>two partitions disappered while windows was running. So far I have rebooted
>a couple of times (before i realized what was going on) and attempted to fix
>the mbr with "FDISK /MBR" which did not fix the problem. I have run
>FindPart and will include the ouput from that below. But after this point I
>am out of my league. Is the output from FindPart enough to restore the
>partitions? I am not concerned with the data on the OS partition. I am
>fine with having to reinstall the OS. It's the data on the other 2 drives
>that I am interested in. Can someone please guide me through this?
>
>Thank you very much.
>
>FindPart Output....................
>
>Findpart, version 4.42.
>Copyright Svend Olaf Mikkelsen, 1999-2004.
>
>OS: DOS 7.10
>
>Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
>--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
>
>------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> 13317 0 33 Second FAT not found.
>
>Partitions according to partition tables on first harddisk:
>
>--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
>
> No signature CHS: 1216 0 1

We need the explanation that the first logical partition is not listed
in the search output.

The most likely explanation seems to be the Windows 98 128 GB or 32 GB
problem, although I did not calculate the scenario, which could be:
data written to the 127712 MB partition were written at wrong
locations, and damaged the first logical, and maybe more, and of
course damaged the structure of the 127712 MB partition too.

Do we have a confirmation that the newest version of Intel Application
Accelerator is installed in Windows 98?

If important data are on the disk, the partitions should be made
hidden, and the disk inserted as disk number 2 in a known good Windows
system for further examination and file copying.
--
Svend Olaf
Anonymous
a b G Storage
March 25, 2005 1:16:14 AM

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

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39kq20F61udc5U2@individual.net
> "Annika K" <none@none.com> wrote in message news:cKednaSILMz1RKnfRVn-tQ@comcast.com
> > Here is my plan of attack...Please look it over and correct any misunderstandings
> > that I may have...
> >
> > First of all, here is the First PTEdit screen before I make any changes....
> >
> > Starting Ending Sectors
> > Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> > ------------------------------------------------------------------
> > 0C 80 0 1 1 191 254 63 63 19,534,977
> > 0F 00 192 0 1 215 254 63 19535040 378,748,440
>
> Hmm.
>
> " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK "
> " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK "
>
> Findpart seems to have a mind of it's own. Svend should look into that.

Svend, your comments please why Findpart shows different values from the actual ones
and not finding a problem with that.

>
> >
[snip]
Anonymous
a b G Storage
March 25, 2005 12:11:01 PM

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

On Thu, 24 Mar 2005 22:16:14 +0100, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39kq20F61udc5U2@individual.net
>> "Annika K" <none@none.com> wrote in message news:cKednaSILMz1RKnfRVn-tQ@comcast.com
>> > Here is my plan of attack...Please look it over and correct any misunderstandings
>> > that I may have...
>> >
>> > First of all, here is the First PTEdit screen before I make any changes....
>> >
>> > Starting Ending Sectors
>> > Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
>> > ------------------------------------------------------------------
>> > 0C 80 0 1 1 191 254 63 63 19,534,977
>> > 0F 00 192 0 1 215 254 63 19535040 378,748,440
>>
>> Hmm.
>>
>> " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK "
>> " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK "
>>
>> Findpart seems to have a mind of it's own. Svend should look into that.
>
>Svend, your comments please why Findpart shows different values from the actual ones
>and not finding a problem with that.
>
>>
>> >
>[snip]

I do not see any problem. The primary FAT32 partition ends cylinder
1215, head 254, sector 63. Ptedit shows the content of the 10 bits for
the cylinder in the partition table entry. Usually 1023 would have
been used in the primary partition table, but I am not aware of any
operating system, which cares.

I guess the original poster mailed me too. My suggestion is that the
partitions are made hidden, and the disk inserted in a known good
Windows system for further examination.

Also see my other message in this thread.
--
Svend Olaf
Anonymous
a b G Storage
March 26, 2005 2:11:01 AM

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

"Svend Olaf Mikkelsen" <svolaf@partitionsupport.com> wrote in message news:4244d3c0.515965@News.Individual.NET
> On Thu, 24 Mar 2005 22:16:14 +0100, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
> > "Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message news:39kq20F61udc5U2@individual.net
> > > "Annika K" <none@none.com> wrote in message news:cKednaSILMz1RKnfRVn-tQ@comcast.com
> > > > Here is my plan of attack...Please look it over and correct any misunderstandings
> > > > that I may have...
> > > >
> > > > First of all, here is the First PTEdit screen before I make any changes....
> > > >
> > > > Starting Ending Sectors
> > > > Type Boot Cyl Head Sector Cyl Head Sector Before Sectors
> > > > ------------------------------------------------------------------
> > > > 0C 80 0 1 1 191 254 63 63 19,534,977
> > > > 0F 00 192 0 1 215 254 63 19535040 378,748,440
> > >
> > > Hmm.
> > >
> > > " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK "
> > > " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK "
> > >
> > > Findpart seems to have a mind of it's own. Svend should look into that.
> >
> > Svend, your comments please why Findpart shows different values from the actual ones
> > and not finding a problem with that.
> >
> > >
> > > >
> > [snip]
>
> I do not see any problem.

Svend, the problem obviously, is that Findpart does not show the
actual values, especially since they are less than 1023 254 63 on
a drive/partition bigger than 8GB.

> The primary FAT32 partition ends cylinder 1215, head 254, sector 63.

> Ptedit shows the content of the 10 bits for the cylinder in the partition
> table entry.

And so should Findpart.
It does that when it is 1023 254 63, but fails to do that when it is not.

> Usually 1023 would have been used in the primary partition table,

Exactly. When it is, Findpart makes a point of that.
Now that it isn't it lies about it and lets us believe that all is OK.
(Actually the fact that it doesn't show the actual values is now an
indication that something is amiss, which is pretty rediculous).

> but I am not aware of any operating system, which cares.

Yes you do. Stop stonewalling, it doesn't become you.

When the CHS isn't what it is supposed to be you can fall prey to the
32GB bug, which is what may have happened to her in the first place.

When CHS sectors is not 63, (when it should have been 63) the drive
will not even boot.

>
> I guess the original poster mailed me too.

You guess.

> My suggestion is that the partitions are made hidden, and the disk
> inserted in a known good Windows system for further examination.

Please define "a known good Windows system".
She probably was on one until this happened to her.

>
> Also see my other message in this thread.

Where you prove that you actually are
"aware of any operating system, which cares".
March 26, 2005 3:15:44 AM

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

"Fart Rienstra" <see_reply-to@myweb.nl> wrote in message
news:3aji21F69fjfdU2@individual.net...

> > > >
> > > > Hmm.

"Hmmm" ... Always a good idea to say that if you don't have a clue and you
want to hide that fact...

> > > >
> > > > " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63
OK OK "
> > > > " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63
OK "
> > > >
> > > > Findpart seems to have a mind of it's own. Svend should look into
that.

Oh he *should*? Maybe you *should* s-t-f-u?

> > >
> > > Svend, your comments please why Findpart shows different values from
the actual ones
> > > and not finding a problem with that.
> > >
> > > >
> > > > >
> > > [snip]
> >
> > I do not see any problem.
>
> Svend, the problem obviously

Perhaps not *that* obvious since he doesn't see it, or me f-w-i-w...

>, is that Findpart does not show the
> actual values, especially since they are less than 1023 254 63 on
> a drive/partition bigger than 8GB.
>
> > The primary FAT32 partition ends cylinder 1215, head 254, sector 63.
>
> > Ptedit shows the content of the 10 bits for the cylinder in the
partition
> > table entry.
>
> And so should Findpart.

Says who? You, F'Nut, the great master of masters of partition tables?

> It does that when it is 1023 254 63, but fails to do that when it is not.
>
> > Usually 1023 would have been used in the primary partition table,
>
> Exactly. When it is, Findpart makes a point of that.
> Now that it isn't it lies about it and lets us believe that all is OK.

And since CHS values are ignored, there actually isn't anything there to be
woried about. However, although your arguments stink, I agree that it would
be nice to see what's actually in the partition table for the simple reason
that Finpart states "Partitions according to partition tables".

> (Actually the fact that it doesn't show the actual values is now an
> indication that something is amiss, which is pretty rediculous).
>
> > but I am not aware of any operating system, which cares.
>
> Yes you do.

WTF F'Nut, when he says he doesn't, he doesn't.

> Stop stonewalling, it doesn't become you.

OMFG ...

>
> When the CHS isn't what it is supposed to be you can fall prey to the
> 32GB bug, which is what may have happened to her in the first place.

What has CHS got to do with 32 Gb bug?

>
> When CHS sectors is not 63, (when it should have been 63) the drive
> will not even boot.

I think it does as long as LBA start is 63. I think I tried that once.

>
> >
> > I guess the original poster mailed me too.
>
> You guess.

That's what he said.

>
> > My suggestion is that the partitions are made hidden, and the disk
> > inserted in a known good Windows system for further examination.
>
> Please define "a known good Windows system".

One that supports the size of the disk?

> She probably was on one until this happened to her.

That remains to be seen

>
> >
> > Also see my other message in this thread.
>
> Where you prove that you actually are
> "aware of any operating system, which cares".

Oh F'Nut, you're so smart! You should have been a lawyer, the way you set up
people and catch their little lies! Or maybe Svend is talking about
something other than CHS values which is relevant?

--
Joepie
Anonymous
a b G Storage
March 26, 2005 2:20:07 PM

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

On Fri, 25 Mar 2005 23:11:01 +0100, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>Svend, the problem obviously, is that Findpart does not show the
>actual values, especially since they are less than 1023 254 63 on
>a drive/partition bigger than 8GB.

I may make mistakes, but I do not think I do in this case. I cannot
use more time on it. No, values shown as larger than 1023 254 63 are
larger than that.

Looking at the output in the original message: There are no Findpart
errors.

Findpart, version 4.42.
Copyright Svend Olaf Mikkelsen, 1999-2004.

OS: DOS 7.10

Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK

------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
13317 0 33 Second FAT not found.

Partitions according to partition tables on first harddisk:

--PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK

No signature CHS: 1216 0 1

--
Svend Olaf
Anonymous
a b G Storage
March 30, 2005 4:44:25 AM

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

"Svend Olaf Mikkelsen" <svolaf@partitionsupport.com> wrote in message news:42454444.3413708@News.Individual.NET
> On Fri, 25 Mar 2005 23:11:01 +0100, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>
> > Svend, the problem obviously, is that Findpart does not show the
> > actual values, especially since they are less than 1023 254 63 on
> > a drive/partition bigger than 8GB.
>
> I may make mistakes,

You? Never.

> but I do not think I do in this case.

Of course you do.

> I cannot use more time on it.

Because it flies you in the face that Findpart is wrong and you will die
before you admit to that, just like you didn't want to admit that using
Int13-AH=48h shouldn't be used for getting CHS even after I showed
you the rules for Int13-AH=48h, that say that the results are invalid
for drives over size 8GB, in
Subject: Total loss of Hard Drive FATs? (Findpart output included)

> No, values shown as larger than 1023 254 63 are larger than that.

That is an obvious oxymoron. But, completely within your style.

Just earlier you said:
"Ptedit shows the content of the 10 bits for the cylinder in the partition
table entry"

And that is because there are only 10 bits in the partition table reserved
for it, so obviously your "values shown as larger than 1023 254 63 "are a
figment of your program's imagination.

>
> Looking at the output in the original message: There are no Findpart errors.

Exactly, and didn't I say that is precisely what was wrong?
It is the values themselfs that are in error as clearly shown by PTEDIT.

>
> Findpart, version 4.42.
> Copyright Svend Olaf Mikkelsen, 1999-2004.
>
> OS: DOS 7.10
>
> Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
>
> ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> 13317 0 33 Second FAT not found.
>
> Partitions according to partition tables on first harddisk:
>
> --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK

And when will you finally correct those overlapping columns?

>
> No signature CHS: 1216 0 1
Anonymous
a b G Storage
March 30, 2005 4:45:01 AM

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

Oh look, the little prat that couldn't distinguish the primary partition from the
last logical and thought that setting the LBA Start was optional, is back after he
disappeared when someone actually could use his help and left it to Zvi and me.
Now that that blew over he dares to come back and be the little prat again.

"Joep" <available@request.nl> wrote in message news:D b16d$42449cdc$3eddca68$6071@nf1.news-service.com
> "Fart Rienstra" <see_reply-to@myweb.nl> wrote in message news:3aji21F69fjfdU2@individual.net...
>
> > > > >
> > > > > Hmm.
>
> "Hmmm" ... Always a good idea to say that if you don't have a clue and you
> want to hide that fact...

Better to disappear for a few days so that others can do the jobs you
don't understand, isn't it Joepie. So you don't have to look foolish.

>
> > > > >
> > > > > " > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK "
> > > > > " > 0 2 0F 19535040 378748440 184935 1216 0 1 24791 254 63 OK "
> > > > >
> > > > > Findpart seems to have a mind of it's own. Svend should look into that.
>
> Oh he *should*?

He'd better.
Or he could setup his own web based support forum like that little brat from
DIYDATARECOVERY has done, so that those that may discover some faults
in their warez won't be able to find out and tell.

> Maybe you *should* s-t-f-u?
>
> > > >
> > > > Svend, your comments please why Findpart shows different values from
> > > > the actual ones and not finding a problem with that.
> > > >
> > > > >
> > > > > >
> > > > [snip]
> > >
> > > I do not see any problem.
> >
> > Svend, the problem obviously,
>
> Perhaps not *that* obvious since he doesn't see it,

Oh, he see's it alright.
Just can't be *seen* to 'see' it because of his 'percepted' reputation.
It is not without reason that he answered to this post and not the other
as that one was far more embarassing.

> or me f-w-i-w...

Well, you are totally expected to not see it. That's no surprise.
The same problem is likely to be existent in your own software since
you all seem to be following each other, copying each others faults.
Seeing it would likely be admitting to having serious errors in your
own software. Can't have that.

"It's not so much that Ptedit won't accept this (more than 1023)
but it is because for cylinder values only 10 bits are available"
You're on record, you stupid little troll.

Showing values that obviously can't fit in the bits assigned to them
obviously is a fault.

>
> > is that Findpart does not show the actual values, especially since they
> > are less than 1023 254 63 on a drive/partition bigger than 8GB.
> >
> > > The primary FAT32 partition ends cylinder 1215, head 254, sector 63.
> >
> > > Ptedit shows the content of the 10 bits for the cylinder in the partition
> > > table entry.
> >
> > And so should Findpart.
>
> Says who? You, F'Nut, the great master of masters of partition tables?

Who was it again that repaired Annika's partition table? You, Svend, Zvi?
Right. Glad we settled that.

>
> > It does that when it is 1023 254 63, but fails to do that when it is not.
> >
> > > Usually 1023 would have been used in the primary partition table,
> >
> > Exactly. When it is, Findpart makes a point of that.
> > Now that it isn't it lies about it and lets us believe that all is OK.
>
> And since CHS values are ignored,

They are not, oh mighty clueless. Svend is pulling wool for your eyes.

> there actually isn't anything there to be woried about.

Even you are not stupid enough that you can't find the posts where Svend
attributes the modulo 32GB bug to CHS values less than 255 heads.
Even you are not stupid enough that you can't find the docs from
Hale Landis's website where the MBR boot code is explained.

> However, although your arguments stink, I agree that it would
> be nice to see what's actually in the partition table for the simple
> reason that Finpart states "Partitions according to partition tables".

Oh goodie, so if he changes the wording he can leave the values be.
Talking about stinking arguments.

>
> > (Actually the fact that it doesn't show the actual values is now an
> > indication that something is amiss, which is pretty rediculous).
> >
> > > but I am not aware of any operating system, which cares.
> >
> > Yes you do.
>
> WTF F'Nut, when he says he doesn't, he doesn't.

Then he better get a good post canceling application and sue Google
to remove his posts before someone proofs him to know better.

>
> > Stop stonewalling, it doesn't become you.
>
> OMFG ...
>
> >
> > When the CHS isn't what it is supposed to be you can fall prey to the
> > 32GB bug, which is what may have happened to her in the first place.
>
> What has CHS got to do with 32 Gb bug?

What, the recovery expert from DIYDATARECOVERY has to ask?
Gee, what a disappointment.

>
> >
> > When CHS sectors is not 63, (when it should have been 63) the drive
> > will not even boot.
>
> I think it does as long as LBA start is 63.

Rotflol. Thanks for showing how stupid you really are.

> I think I tried that once.

You 'think', huh? Try again.

You don't have a single clue to what code is in the MBR, haven't you, Joepie.
I know *for fact* that if you clear the CHS values the system does not
boot with a Win98 MBR(boot)sector as it only uses the CHS Int13/AH=02.
The W2k MBR code is a little smarter but only uses LBA Int13/AH=42 *if*
the partition bootsector is out of reach for CHS Int13/AH=02 as reported
by Drive Parameters Int 13/AH=08h.
So for the bios at Auto and the boot partiton whithin the first
8GB it too will use CHS Int13 with the MBR supplied CHS values.

>
> >
> > >
> > > I guess the original poster mailed me too.
> >
> > You guess.
>
> That's what he said.
>
> >
> > > My suggestion is that the partitions are made hidden, and the disk
> > > inserted in a known good Windows system for further examination.
> >
> > Please define "a known good Windows system".
>
> One that supports the size of the disk?
>
> > She probably was on one until this happened to her.
>
> That remains to be seen

Exactly. You don't know it until something happens to prove otherwise.
Apparently Svend's GB32 program can tell so that could have been one
answer to that question but for some reason he chose to keep quiet about it.
Maybe it has flaws too. As a matter of fact, I pointed them out to him once.

Maybe "he couldnot use more time on that" too.

>
> >
> > >
> > > Also see my other message in this thread.
> >
> > Where you prove that you actually are
> > "aware of any operating system, which cares".
>
> Oh F'Nut, you're so smart! You should have been a lawyer, the way you set up
> people and catch their little lies!

Thanks for pointing out that he lied.

> Or maybe Svend is talking about something other than CHS values which is relevant?

Nope, and even someone as stupid as you can find those posts about the modulo
32 GB bug with the help of Google: "This is the 2nd time My HD's Been Corrupt"
April 1, 2005 3:52:32 AM

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

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:4249e8a1$0$97727$892e7fe2@authen.white.readfreenews.net...
> "Svend Olaf Mikkelsen" <svolaf@partitionsupport.com> wrote in message
news:42454444.3413708@News.Individual.NET
> > On Fri, 25 Mar 2005 23:11:01 +0100, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:
> >
> > > Svend, the problem obviously, is that Findpart does not show the
> > > actual values, especially since they are less than 1023 254 63 on
> > > a drive/partition bigger than 8GB.
> >
> > I may make mistakes,
>
> You? Never.
>
> > but I do not think I do in this case.
>
> Of course you do.
>
> > I cannot use more time on it.
>
> Because it flies you in the face that Findpart is wrong and you will die
> before you admit to that, just like you didn't want to admit that using
> Int13-AH=48h shouldn't be used for getting CHS even after I showed
> you the rules for Int13-AH=48h, that say that the results are invalid
> for drives over size 8GB, in
> Subject: Total loss of Hard Drive FATs? (Findpart output included)

Oh, right, that must be it. Loser!

>
> > No, values shown as larger than 1023 254 63 are larger than that.
>
> That is an obvious oxymoron. But, completely within your style.
>
> Just earlier you said:
> "Ptedit shows the content of the 10 bits for the cylinder in the partition
> table entry"
>
> And that is because there are only 10 bits in the partition table reserved
> for it,

And you think you need to explain that?

> so obviously your "values shown as larger than 1023 254 63 "are a
> figment of your program's imagination.
>

Maybe you're right. Imagination is something you know about.

> >
> > Looking at the output in the original message: There are no Findpart
errors.
>
> Exactly, and didn't I say that is precisely what was wrong?
> It is the values themselfs that are in error as clearly shown by PTEDIT.
>
> >
> > Findpart, version 4.42.
> > Copyright Svend Olaf Mikkelsen, 1999-2004.
> >
> > OS: DOS 7.10
> >
> > Disk: 1 Cylinders: 24792 Heads: 255 Sectors: 63 MB: 194474
> >
> > --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> > 0 - 0C 63 19534977 9538 0 1 1 1215 254 63 B OK
> > 8511 1 0B 63261554202127712 8511 1 1 24791 254 63 OK OK
> >
> > ------FAT CHS -Size Cl --Root -Good -Rep. Maybe --Bad YY-MM-DD DataMB
> > 0 1 33 9530 8 2 9530 0 0 0 05-03-07 454
> > 8511 1 33 31921 32 2 31921 0 0 0 05-02-21 75808
> > 13317 0 33 Second FAT not found.
> >
> > Partitions according to partition tables on first harddisk:
> >
> > --PCyl N ID -----Rel -----Num ---MB --Start CHS- ---End CHS-- BS CHS
> > 0 1*0C 63 19534977 9538 0 1 1 1215 254 63 OK OK
> > 0 2 0F 19535040378748440184935 1216 0 1 24791 254 63 OK
>
> And when will you finally correct those overlapping columns?

Hahaha ... F'Nut, you really need professional care! Who the F*** you think
you are?

>
> >
> > No signature CHS: 1216 0 1

--
Joepie
!