Topic: HELP REQUEST: How does GParted deal with Windows MBR partitions?

On my Microsoft Windows 10 laptop, I have non-contiguous unallocated space on a MBR partition that I want to move to after an existing partition so I can extend that partition.

There are recovery partitions between the unallocated space and the partition I want to extend, which I want to remain unaffected by moving the unallocated space to after the partition I want to extend.

The following is a list of volumes/partitions in contiguous order on my laptop, initially generated by Windows diskpart and subsequently enhanced by me with additional information:

Disk # Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
------ ----------  ---  -----------  -----  ----------  -------  ---------  --------
Disk 0 Volume 1         System Rese  NTFS   Partition    100 MB  Healthy    System
Disk 0 Volume 9         UNALLOCATED
Disk 0 Volume 3         Recovery 1   NTFS   Partition    508 MB  Healthy    Hidden
Disk 0 Volume 4         Recovery 2   NTFS   Partition    468 MB  Healthy    Hidden
Disk 0 Volume 2     E   Data2        NTFS   Partition    366 GB  Healthy

Disk 1 Volume 5     C   Windows 10   NTFS   Partition     95 GB  Healthy    Boot
Disk 1 Volume 7         Recovery 3   NTFS   Partition    970 MB  Healthy    Hidden
Disk 1 Volume 8         Recovery 4   NTFS   Partition    782 MB  Healthy    Hidden
Disk 1 Volume 6     D   Data         NTFS   Partition    368 GB  Healthy

This post is relevant to Disk 0 above, but details for Disk 1 are listed for completeness.

All partitions are MBR, not GPT.

Ideally I would like to keep partitions as MBR and not convert to GPT to avoid any potential loss of or any adverse impact upon any of the recovery partitions.

The task I want to achieve is to move UNALLOCATED volume 9 to after volume 2 without having any impact whatsoever on the recovery volumes 3 and 4.

Can GParted do this?


Re: HELP REQUEST: How does GParted deal with Windows MBR partitions?

I understand that you have 2 hard drives (or SSDs) in the laptop.
You can use GParted to manipulate partitioning as far as these drives are "basic" drives, not "dynamic" drives. You can look for this in the "Manage" / storage management of your operating system.

MBR partition system allows up to 4 primary partitions on each drive, or 3 primary and 1 extended where you can put more "logical" partitions. From the above info I can't see if "Unallocated" is just a disk empty space that doesn't belong to any partition or it is a partition without any filesystem inside (unformatted).
You can't "move" empty disk space, you can move other partitions so that the empty space is left in the position you want to be.
For the logical partitions in the eventual extended partition you have to resize the extended partition before doing anything with the contained partitions. The extended partition is a kind of container, and it is a concept that comes from the years 1980. With GPT there is no extended partition because the partition table can contain much more entries (up to 128 partitions if I remember well).

In order to know what exactly happens, you can boot the computer from a GParted live cd or USB stick, and run GParted. The main screen shows one drive each time, in graphical format. It is easy to find there if there is any extended partition as well as the right position of the partitions on disk.
From the terminal window of the GParted live cd/usb (or from the terminal in any GNU/Linux distribution) you can run the commands

sudo fdisk -l -u 

that gives info on all drives of the system, or

sudo fdisk -l -u /dev/sda
sudo fdisk -l -u /dev/sdb

for the drives   /dev/sda  and  /dev/sdb  that are usually the first two hard drives connected to the system.

Additional info can be found from the commands

sudo parted /dev/sda unit s print
sudo gdisk -l /dev/sda

(replace sda with your drive's designation if different).

You also can find a similar graphical image from the storage management or disk management of your system.

Before any modification of the partition system, please keep backup of anything important in your system (this is valid for any partition managing system, including gparted and diskpart. Many of the problems reported here concern data loss that could be not important if a good backup was available). There are always risks not only from software bugs but (mostly) from hardware issues, power loss, bad connectors, RAM problems.

*** It is highly recommended to backup any important files before doing resize/move operations. ***