[Gptfdisk-general] sgdisk off-by-one error with negative start positions

[Parke <par...@gm...>]

Hello,

With sgdisk version 1.0.8 on Ubuntu 22.04, I am observing an
(apparent) off-by-one error with commands that use negative start
positions.

I don't see this issue mentioned in the NEWS file at SourceForge, so I
am guessing it may still exist.

Consider the following two commands, run on a GPT disk with no partitions:

sgdisk /dev/sdb --new=4:-20m --typecode=4:ef00
sgdisk /dev/sdb --new=3:-500m --typecode=3:8300

Information: Moved requested sector from 29990256 to 29988864 in
order to align on 2048-sector boundaries.

Information: Moved requested sector from 28964863 to 28962816 in
order to align on 2048-sector boundaries.

Then run gdisk -l /dev/sdb:

[snip]
Number  Start (sector)    End (sector)  Size       Code  Name
   3        28962816        29988863   501.0 MiB   8300  [snip]
   4        29988864        30031216   20.7 MiB    EF00  [snip]

Note that partition 3 was requested to be -500M, but its actual size
is (exactly) 501MiB.

Partition 4 does not end on a 2048-sector boundary.  Therefore, it is
understandable that partition 4 is larger than the requested -20M.

However, partition 3 does end on a 2048-sector boundary.  Therefore,
partition 3 could be exactly 500MiB.  Instead, it is 501MiB.

I suspect what is happening is exactly what is described in sgdisk's manpage.

    You can specify loca‐
    tions relative to the start or  end  of  the  specified  default
    range  by preceding the number by a '+' or '-' symbol, as in +2G
    to specify a point 2GiB after the default start sector, or -200M
    to  specify  a  point 200MiB before the last available sector.

If the last available sector is immediately before a 2048-sector
boundary, then rewinding 200M will place you one sector before another
2048-sector boundary.  sgdisk will then rewind further to the next
2048-sector boundary.  This adds an extra megabyte to the size of the
partition.

To create a 200M partition when -200M is specified, I believe the
offset should instead be calculated from the sector **immediately
after** the last available sector.

Cheers,

Parke