After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738144 - Bug that automatically resizes partitions when moving them to the end of the disk
Bug that automatically resizes partitions when moving them to the end of the ...
Status: RESOLVED OBSOLETE
Product: gparted
Classification: Other
Component: application
0.19.1
Other Linux
: Normal major
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2014-10-08 10:57 UTC by gnomebugs2
Modified: 2020-11-13 10:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description gnomebugs2 2014-10-08 10:57:59 UTC
Hello foks, this is a weird one.

When moving partitions to the right, in some cases gparted behaves very weird. The behaviour is best described with some reproduction steps.

How to reproduces the bug:
Take an empty disk (a sparse file should be okay too). I think it is important that number of sectors on the disk is not divisible by 2048. The disk I used has 62533296 sectors and a gpt partition table.

In fact, these are actually two bugs, but I think they are related. The first one:
Create a partition (type should not matter, try ext4) with size 1024 MiB at the beginning of the disk. Apply the operation. Now move the partition to the end of the disk, either by moving it with the mouse or by typing "0" into the "Free space following" field. Press OK in the move dialog and see how a "Move /dev/sdX1 to the right and shrink it from 1.00 GiB to 1023.00 MiB" appears in the pending operations list. The partition is still aligned afterwars, but shrinked by 1 MiB. I think the desired behaviour should be not to shrink the partition.

If you leave (at least) 1 MiB free space following the partition, this behaviour does not occour.

To reproduce the second bug, remove the paritions again, and create the following two:
1024 MiB at the beginning of the drive
1024 MiB with at maximum 1024 MiB free space following. The free space following must be at maximum the size of the partition in order to reproduce the bug.

Apply the creation.

Now move the second partition to the end. It does not matter whether you leave 0 or some MiB free after the partition. Don't hit apply yet, otherwise it won't work. Now move the first partition next to the second with 0 MiB free space between them. You will see that gparted will generate a "move and shrink from 1 GiB to 1023 MiB"-operation for the first partition. Afterwards, it will have shrinked the first partition and moved it next to the second partition with a 1 MiB gap between them.

If you apply the operations between the two moves, everything works fine.

Some remarks: When moving a partition to the end, leaving 1 MiB of free space afterwards, gparted decides to leave some sectors, but not 1 MiB. Leaving 2 MiB causes 1 MiB + some sectors of free space afterwards. I think the wanted behaviour is when the user want's to leave 1 MiB free, there should be _at least_ 1 MiB (1 MiB + the rest of the sectors that don't make up another MiB).
Comment 1 André Klapper 2020-11-13 10:41:13 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at
https://gitlab.gnome.org/GNOME/gparted/-/issues/
by following the guidelines at
https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines

Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).