Subject: Inconsistent interpretation of end specifications

From: Joshua Krämer <[email-masked]>
Date: Sun, 10 Apr 2022 13:47:33 +0200

Dear parted developers,

the mkpart end specification seems to be interpreted differently
depending on the given unit. If the end location is given in s, B or
KiB, it seems to be interpreted as the offset of the partition's last
sector:

| $ parted test.img
| WARNING: You are not superuser.  Watch out for permissions.
| GNU Parted 3.4
| Using /home/joshua/parted/test.img
| Welcome to GNU Parted! Type 'help' to view a list of commands.
| (parted) mkpart test 2048s 4096s
| (parted) unit s
| (parted) print
| Model:  (file)
| Disk /home/joshua/parted/test.img: 6144s
| Sector size (logical/physical): 512B/512B
| Partition Table: gpt
| Disk Flags:
|
| Number  Start  End    Size   File system  Name  Flags
|  1      2048s  4096s  2049s               test

"mkpart test 1048576B 2097152B" and "mkpart test 1024KiB 2048KiB" give
the same result. However, if the end is specified in MiB, it seems to
be interpreted as the offset of the first sector after the partition's
end:

| (parted) mkpart test 1MiB 2MiB
| (parted) print
| Model:  (file)
| Disk /home/joshua/parted/test.img: 6144s
| Sector size (logical/physical): 512B/512B
| Partition Table: gpt
| Disk Flags:
|
| Number  Start  End    Size   File system  Name  Flags
|  1      2048s  4095s  2048s               test

The meaning of the end specification with the print command seems to
be different as well. I think it represents the offset of the first
sector after the partition's end minus 1 unit (rounded):

| (parted) mkpart test 1048576B 2097152B
| (parted) unit B
| (parted) print
| Model:  (file)
| Disk /home/joshua/parted/test.img: 3145728B
| Sector size (logical/physical): 512B/512B
| Partition Table: gpt
| Disk Flags:
|
| Number  Start     End       Size      File system  Name  Flags
|  1      1048576B  2097663B  1049088B               test

If there is a reason for these inconsistencies, I think they should be
clearly described in the documentation.

Thanks for your work and kind regards,
Joshua Krämer