Convert drive to on disk partition table.

psyko_chewbacca NA repo owner

changed status to on hold

Yes it would be possible but there might be a few situations where attempting this could result in hard drive corruption.

The only automated way of doing this would be to scan for a G partition header at the 137GB LBA offset to see if it's there. If it's there, we just need to follow the ".67" partition scheme. If there isn't we could assume that the F partition takes up the rest of the drive, assuming there is indeed a partition header at the appropriate location, then follow the ".06" partition scheme.

Doing this could potentially harm the data integrity in certain situation. Mainly if people have their drives formatted with very old BIOS.

On the top of my head, an example would be someone with a 160GB hard drive which would have been formatted with non-LBA48 BIOS. It would contain a single F partition that would end at the 137GB boundary; leaving an unused area at the end of the drive of 23GB (not really, just to round numbers). Adding a partition table this way, XBlast OS, would just assume the F drive takes up the rest of the drive, including the unused 23GB at the end (as it wouldn't find a G partition header at 137GB; because there is no way for XBlast OS to know the partition stops at the 137GB boundary. It would expand the size of the partition but in the process, would also expand the allocated FAT table at the start of the partition that would eventually overwrite the starting clusters containing file/directory entries for the root of the partition as you're starting to access the last 23GB of the drive.

That's just one example but maybe there are others.

The other way around this would be to let the user impose a partition table but that opens the door to user error and consequently data loss.

In the end, I'm not sure if it's worth it. Hacked BIOSes can work fine without a partition table.

I'll put this one on hold, and consider it when I have some slack.

2018-07-23T12:03:58+00:00

Comments (1)

psyko_chewbacca NA repo owner
- changed status to on hold
Yes it would be possible but there might be a few situations where attempting this could result in hard drive corruption.

The only automated way of doing this would be to scan for a G partition header at the 137GB LBA offset to see if it's there. If it's there, we just need to follow the ".67" partition scheme. If there isn't we could assume that the F partition takes up the rest of the drive, assuming there is indeed a partition header at the appropriate location, then follow the ".06" partition scheme.

Doing this could potentially harm the data integrity in certain situation. Mainly if people have their drives formatted with very old BIOS.

On the top of my head, an example would be someone with a 160GB hard drive which would have been formatted with non-LBA48 BIOS. It would contain a single F partition that would end at the 137GB boundary; leaving an unused area at the end of the drive of 23GB (not really, just to round numbers). Adding a partition table this way, XBlast OS, would just assume the F drive takes up the rest of the drive, including the unused 23GB at the end (as it wouldn't find a G partition header at 137GB; because there is no way for XBlast OS to know the partition stops at the 137GB boundary. It would expand the size of the partition but in the process, would also expand the allocated FAT table at the start of the partition that would eventually overwrite the starting clusters containing file/directory entries for the root of the partition as you're starting to access the last 23GB of the drive.

That's just one example but maybe there are others.

The other way around this would be to let the user impose a partition table but that opens the door to user error and consequently data loss.

In the end, I'm not sure if it's worth it. Hacked BIOSes can work fine without a partition table.

I'll put this one on hold, and consider it when I have some slack.
- 2018-07-23T12:03:58+00:00
Log in to comment