problem finding FAT16 file data offset

[miker00lz]

i've got a similar issue to nessphoro's FAT32 cluster issue in the other thread, but not quite so i thought i'd start a new thread instead.

my FAT16 driver is not calculating the correct data offset from the first cluster given in a file entry. screenshot to show what it's reading:




the actual first line of the file should read "@ECHO OFF"... this is how i'm calculating the absolute byte offset on the hard disk:

fatvolume[part].data + (fatvolume[part].bytesperclust * file[handle].f_clust)

file[handle].f_clust represents the first cluster number of the file from it's directory entry. fatvolume[part].data is the offset in absolute bytes (from the very first sector of the disk) to the beginning of the partition's data area.

what am i messing up here?

[Combuster]

You just opened a zipfile instead...

I have the idea your cluster offset is wrong. Normally autoexec.bat would be expected to be one of the first files on disk, not at 25% of the storage capacity. Do you have the exact sector offset to that file?

[miker00lz]

You just opened a zipfile instead...

I have the idea your cluster offset is wrong. Normally autoexec.bat would be expected to be one of the first files on disk, not at 25% of the storage capacity. Do you have the exact sector offset to that file?

yeah that caught my eye too, should have been much closer to the front of the data area, although i've done a lot of stuff on this particular image file, and i'm sure i've deleted/remade autoexec.bat more than once so that could explain it.

here's a hex dump of the actual directory entry for the file:



my cluster value appears accurate based on that, 0x2746 is 10054 decimal. about the sector offset, do you know of any really good disk image editors that can give me that information? winimage doesn't seem to be able to tell me. it looks like my code is trying to read from sector 2228224.. wow how did that happen?

this is the code that generates the partition offset data when the volume is first found:

Code: Select all

                fatvolume[partcount].offset = mbr[drive].part[i].f_lba*512;
                if (!disk_read(drive|0x80, mbr[drive].part[i].f_lba*512, (uint8 far *)FARPTR(_CS, &fatvolume[partcount]), sizeof(fatvolume[0].bpb))) {
                    ttyprint(maintty, " [Kernel] BPB read error\r\n");
                    break;
                }
                fatvolume[partcount].fatloc = fatvolume[partcount].offset + (uint32)fatvolume[partcount].bpb.reservedsects*512;
                fatvolume[partcount].root = fatvolume[partcount].fatloc + ((uint32)fatvolume[partcount].bpb.numfats*(uint32)fatvolume[partcount].bpb.sectsperfat*512);
                fatvolume[partcount].data = fatvolume[partcount].root + (((((uint32)fatvolume[partcount].bpb.maxroot*32)+511)/512)*512);
                fatvolume[partcount].bytesperclust = (uint32)fatvolume[partcount].bpb.bytespersect * (uint32)fatvolume[partcount].bpb.sectsperclust;

at least fatvolume[partcount].offset, .fatloc and .root are correct because it correctly reads root directory entries. there's probably something stupid that i did staring me right in the face that i can't see.

[Combuster]

do you know of any really good disk image editors that can give me that information?

I'd use an hex editor instead and search for the actual file contents

[miker00lz]

do you know of any really good disk image editors that can give me that information?

I'd use an hex editor instead and search for the actual file contents

d'oh! yeah, derp. of course.

i did so, the file starts at byte offset 41,427,968... so sector 80,914.

[miker00lz]

got it! my bytes per cluster value was incorrect, and i wasn't subtracting 2 from the first cluster also. what is the reason for needing to subract 2 exactly?

[Nessphoro]

Well, the first two clusters are reserved, one for BPB and one for FAT, though I do not know why they did it, but that's how it works.

[miker00lz]

yeah, but i mean i wonder why they didn't just make the first cluster value start at the actual data area. i don't think they thought the format out very thoroughly. i guess they were in a rush to make something that worked.

[Nessphoro]

They're always are.

[egos]

Really it has historical reason.