Extended partition table...

[tipul07]

Hi guys,

I'm writing a small app that should read details about partitions on a hdd. Everything works fine reading primary partitions (including details about extended partition - starting sector/block, size etc). Basically I can get info about primary partitions in a structure like this:

#define HDD_SECTOR_SIZE     512

typedef struct mbrp {
    unsigned char boot_ind;         /* 0x80 - active */
    unsigned char head;             /* starting head */
    unsigned char sector;           /* starting sector */
    unsigned char cyl;              /* starting cylinder */
    unsigned char sys_ind;          /* What partition type */
    unsigned char end_head;         /* end head */
    unsigned char end_sector;       /* end sector */
    unsigned char end_cyl;          /* end cylinder */
    unsigned char start4[4];        /* starting sector counting from 0 */
    unsigned char size4[4];         /* nr of sectors in partition */
} mbr_partition;


#define ALIGNMENT 2
typedef union ptab {
    struct {
        unsigned char align[ALIGNMENT];
        unsigned char b[HDD_SECTOR_SIZE];
    } c;
    struct {
        unsigned char align[ALIGNMENT];
        unsigned char buffer[0x1BE];
        mbr_partition part[4];
        unsigned char magicflag[2];
    } p;
} partition_table;

After I identify extended partition. I seek at partition_table.p.part[x].start4 * HDD_SECTOR_SIZE (where x is index of extended partition table from the 4 primary partitions) using function:

bool read_sector( unsigned char *buffer, long long sect_num )
{
  if( lseek( fd, sect_num*HDD_SECTOR_SIZE, SEEK_SET) < 0)
      return false;
  if (read(fd, buffer, HDD_SECTOR_SIZE) != HDD_SECTOR_SIZE)
      return false;
  return true;
}

Problem I have is that if I seek and read (with function above) what should be extended partition table I get all junk.
If I use tho dd like: dd if=/dev/sda of=ept.txt count=1 bs=512 skip=x (where x is starting sector of extended partition) I get good results (a valid extended partition table info).

Do I miss something here? Should I do something extra to get right extended partition table?

Regards,
Andy

[Lostfarmer]

First off I know not a thing about programming so could be way off. The start sector # you will read from the Master Partition Table start counting from the # zero but the program likley will start from #1 so a -1 offset might be needed someplace.

You might beable to add a function to save the sector your program reads to a file and then look at it and determine just what sector is indeed being read.

[tipul07]

First off I know not a thing about programming so could be way off. The start sector # you will read from the Master Partition Table start counting from the # zero but the program likley will start from #1 so a -1 offset might be needed someplace.

You might beable to add a function to save the sector your program reads to a file and then look at it and determine just what sector is indeed being read.

Well actually Master Boot Record sits at sector 0 on the hdd, rest of sectors/blocks up to sector 64 should be left empty. So you would get an offset of 63 sectors if you would want to read sector 1 of first primary partition. Same rule applies for extended partition tables. The very first sector of the extended partition will be partition table and rest of 63 would remain empty. If there are more than 1 extended partition you would have to read extended primary partition to get location of next extended partition in the chain and so on...

Well this is the theory... My problem is that I cannot read first extended primary partition... When I dump the 512 bytes buffer at sector where extended partition should start I get only junk (like seek function would fail).

When I developed the code I used cfdisk.c as example. Tried with open/close/lseek/read and also with fopen/fclose/fseek/fread series... At least I get same junk bytes all the time so they work similarly...

Could it be bcuz of tool chain used to compile the applications?

When I custom compiled dd.c source code (dd2 bin file) I got with ldd:

ldd ./dd2
linux-gate.so.1 =>  (0xb7f07000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d89000)
/lib/ld-linux.so.2 (0xb7f08000)

And on distribution binary dd file I got:

ldd /bin/dd
linux-gate.so.1 =>  (0xb8027000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb8003000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7ea0000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e86000)
/lib/ld-linux.so.2 (0xb8028000)

Note: My Kubuntu distribution is:

Linux andy-desktop 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

[Lostfarmer]

You might get a clue on your problem by looking at below codes, due to my lack of programing, not sure and will say good luck and bye.

Koders Code Search: sfdisk.c - C - GPL

Koders Code Search: mbrdecode.cpp - C++

[tipul07]

You might get a clue on your problem by looking at below codes, due to my lack of programing, not sure and will say good luck and bye.

Koders Code Search: sfdisk.c - C - GPL

Koders Code Search: mbrdecode.cpp - C++

GREAT!!!

Thank you so very much! Problem was that I was using 32 bits version of seek function so it was indeed failing... So I switched to llseek/lseek64 version and it works like a charm!

Thank you for mbrdecode.cpp example!

Regards,
Andy

[Lakshmipathi]

Could it be bcuz of tool chain used to compile the applications?

I'm sure it coule never be tool chain issue and wondering what it could be

Thank you so very much! Problem was that I was using 32 bits version of seek function so it was indeed failing... So I switched to llseek/lseek64 version and it works like a charm!

glad you found out yourself,(thanks to Lostfarmer ) ,While writing my tool I had an issue (accessing location greater than 4294967295 )
Later when i replaced lseek with lseek64 ,it worked fine.

[Lostfarmer]

I could not understand the code at all but glad it helped.