DOS ain't dead

> Btw, does this forum software have no possibility to somehow select a fixed
> font?

You can (ab)use the code tag for that.

---
Forum admin

> On the subject of partitioning utilities, there is parted here:

the subject is "Current FreeDOS fdisk utility", not "partitioning utilities".

could you please spam some other forum?

> On the subject of partitioning utilities, there is parted here:

the subject is "Current FreeDOS fdisk utility", not "partitioning utilities".

could you please spam some other forum?

edited to add: or at least create a new thread?

> FreeCOM should probably specify system requirements, though.

yes of course. FreeCOM requires a DOS-compatible operating system.

> Would't you try to compare the partition creation using MS-DOS 6.2x FDISK
> (on smaller partition) if it lead to same problem?
>
> BI Type                    Start-C/H/S   End-C/H/S     Sector     Size   
> MB  abs. Start/End
> ----------------------------------------------------------------------------------------------
> 80 0e Prim. DOS,FAT16,LBA     0/  1/ 1  975/ 63/32         32    4096000
> 2000 32-4096031
> 00 0c Prim. DOS,FAT32,LBA   976/  0/ 1  534/ 63/32    4096000  120731648
> 58951
>
> Well I see the problem here. It's tricky that cylinder value already
> overflows 10bit storage in partition entry. One simple approach would be to
> start next partition just by incrementing the cylinder of previous end
> value (975+1)&0x3FF=976.

fortunately, this is not the way FDISK works. all internal work is done with (unfortunately signed) 32 bit cylinders.
otherwise, it would have failed much earlier.

> Other approach would be to calculate CHS from LBA
> value. Last LBA is 4096031 so next partition should start at LBA 4096032 or
> further. If one do simple calculation like 4096032/64/32=2000.015625 and
> truncate it to 2000 then & 3FF = 976 and things goes wrong. It should check
> the reminder and round up to 2001 then & 3FF = 977. Back to LBA it would
> give 4098048 so ~1MB wasted gap but better than overlap.


impressive insights.
however, FDISK already tries to work this way; I'm simply not able to spot where it fails.

> and it would be really interesting to learn what Windows/Linux to with such
> damaged partitions.

I remember encountering this somehow with CentOS 7 bootable USB images. They had the EFI partition, which is basically a FAT file system, embedded as an image file inside the ISO image, and in the partition table a separate entry would carefully reference this image inside the larger data partition.

> > I think I understand the problem now, and it's not easy to fix.
> >
> > for ease of arithmetic, assume a cylinder size of 1000 sectors.
> >
> > if an existing 4500 sector partition extends from 5200 to 9700, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is happy.
> >
> > if an existing 4500 sector partition extends from 5600 to 10100, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is unhappy (sooner or later).
>
> I do not understand...
exactly. You do not understand.
It could help to read the relevant source code; search for Read_Partitiontables().


> Why should FDISK "round down" the
> start or end of the partition at all? It always has to
> round AWAY from the actual start and end of existing
> partitions. So in your example, if new partitions are
> to have boundaries which are multiples of 1000 sectors,
> the previous partition has to end at or before 5000 in
> both examples and the next partition has to start at
> 10000 or later in the first and 11000 or later in the
> second example. Rounding to NEAREST cylinder boundaries
> seems to be always a bad idea?
it's not 'rounding to NEAREST'. it's round DOWN for partition start,
round UP for (partition end + partition size). basically, FDISK thinks that partitions start at head=0, sector = 1, and end at head = 255, sector 63.


> Or are you saying the rounding just fails to know whether
> it has to be up or rather down at the relevant moment, so
> the author decided to simply round to nearest all times?
no.

> Regarding your next post: You say it would be hard to mark
> clusters in non-FAT filesystems as blocked. My assumption
> was that the FDISK bug only makes the END of FAT partitions
> overlap later partitions.
this bug has absolutely nothing to do with partition types.

> I agree that it is a good thing if the KERNEL detects any
> overlaps. Which makes me wonder whether it would be easy
> to automatically block access to trailing overlapping FAT
> clusters?
I really doubt other OS will implement code not to overwrite
partitions created by some buggy FDISK.

> Of course that still will not help you when the
> partitions are also accessed by OTHER operating systems, so
> a tool to mark overlapping clusters bad still sounds good.
Sure. And of course, you are not in charge to create such a tool

> unfortunately, the package as delivered doesn't compile as catgets.* is
> missing.

But I see a cats396s\include\catgets.h and cats396s\lib\catgets.c.

In the meantime I found another 2 bugs:

- on a computer with an USB card reader, if I try to start fdisk, the program terminates with message "divide error". The USB card reader adds 4 drives to the BIOS, which - as long as there's no "card" inserted" - are reported having CYL/HEAD/SECT=0/0/0 and sector size = 0.

- on another machine with a GPT-partitioned disk ( having a "protective" MBR), fdisk thinks that 100% of the disk are free and happily creates a primary partition. During the creation process fdisk writes a few sectors filled with 0xf6 to the partition start - might do some damage to an installed windows/linux.

---
MS-DOS forever!

> > I think I understand the problem now, and it's not easy to fix.
> >
> > for ease of arithmetic, assume a cylinder size of 1000 sectors.
> >
> > if an existing 4500 sector partition extends from 5200 to 9700, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is happy.
> >
> > if an existing 4500 sector partition extends from 5600 to 10100, FDISK
> will
> > "round down" this partition to 5000 through 9999, will create the next
> > partition at 10000, and everybody is unhappy (sooner or later).
>
> unfortunately, I think my explanation was wrong, at least as far as
> Read_Partiton_Tables() is concerned. IMO this should work as expected.
>
> the bug must be somewhere else.
>
> unfortunately, the package as delivered doesn't compile as catgets.* is
> missing.

I found and fixed it in FDISK 1.22

like in a difficult Sudoku after the expert pointed it out to you.
once you see it, it's easy to see.

PDISKIO.C, line 954-964 should be changed to

          pDrive->pri_part[index].end_head=pDrive->total_head;
          pDrive->pri_part[index].end_sect=pDrive->total_sect;
          pDrive->pri_part[index].end_cyl
           =Extract_Cylinder_From_LBA_Value(
           /* */
           (pDrive->pri_part[index].rel_sect
           +pDrive->pri_part[index].num_sect)
          0,                           // !!,pDrive->pri_part[index].end_head
           1,                           // !!,pDrive->pri_part[index].end_sect
       ,pDrive->total_head
           ,pDrive->total_sect);


and similarly 1071 through 1091.

I will see if I can fix Japheth's recent 2 bugs.