Talk:GParted

Untitled

The Extended Partition type must be included in any discussion of partitions. GParted does operate on it: The fact that the GParted project's own documentation is lacking is no reason to impoverish our Wikipedia article. Intersofia (talk) 12:52, 13 March 2008 (UTC)

Merger proposal

Sure, why not? 4.242.108.196 (talk) 16:43, 16 June 2008 (UTC)

Disagree --Hm2k (talk) 09:11, 27 July 2009 (UTC)

Sources

We need some primary sources for this article. I'm sure they exist.

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

--Hm2k (talk) 09:11, 27 July 2009 (UTC)

OS

Live usb or cd are no operationg systems.--Baruch ben Alexander - ☠☢☣ 22:22, 8 June 2010 (UTC)

An article about a UNIX tool that "contains too much jargon"? Really? —Preceding unsigned comment added by 173.55.117.56 (talk) 23:25, 24 November 2010 (UTC)

ExFat

gparted 0.10.0 an detect exfat, I dont know how or wat is need, but is detectable and recongiceable — Preceding unsigned comment added by 190.20.42.45 (talk) 20:45, 8 November 2011 (UTC)

Warning Required - Don't Do It

This article is fine and all, and I realise Wikipedia is not meant to teach how, and instead discuss what, but this page needs a Warning section. These "advanced" repartitioning tools are popular because usually the basic, built-in tools won't do many of the operations (e.g. move) we want to do. There's a reason for it: they're dangerous. Ignoring the fact that a disk error during a move operation can be fatal, any errors or corruption in the partition table can cause complete data loss. Unfortunately this data loss may not happen until days later, after the backups are out of date.

Safe operations are deletion, creation and extending a partition into empty space immediately after a partition. Shrinking the end of a partition where the end of the partition is not used is also safe, although one has to be careful there are no files or fragments in this space at the end. Pretty much all other operations are unsafe, definitely everything that requires the movement of data or the file table (MFT, FAT, whatever).

E.g. suppose you have an OS partition C:, and then a data partition D:, in that order. You have to expand C: because you made it too small (we all do). Do not shrink and move D: so that you can expand C:. Defragment D: (so you can shrink it), make an image backup of D:, test your image, delete D:, extend C:, recreate a smaller D: and restore the D: image into the new, smaller D: partition. If you cannot restore an image to a smaller partition, defrag D: (and check the analysis to be sure the end is empty), shrink D:, then make the image backup. (Or, you know, invest in better backup tools instead of partition tools, free or otherwise.)

I know it sounds more dangerous, but it is in fact safer. There are too many operations in a move that requires everything to go right. Just last year my co-worker used GParted to perform this same operation in the obvious (but dangerous) way (he didn't ask around first), and 2 days later we lost all of the data in the D: partition.

This is not the first time I have had damaged partitions after these operations. The partition table had an error where the C: partition overlapped into the D: partition. (It's a flaw inherent is these offset+size table designs.) Unfortunately this error did not cause problems at first. Eventually data written to the overlap of C: overwrote the MFT of D:, and there goes your file system. Unfortunately the image backups are out of date by the time you realise. Besides, restoring a partition image is faster than moving its data. And we're all making disaster recovery images and testing them anyway, right?

Sure these unsafe ops will work most of the time, but once you're a grizzled IT person and you've lost a few partitions (it's what makes you grizzled), you'll sing a different tune. There are good reasons why the built-in OS tools don't let you do these operations. Just don't do it.

Be safe, you'll miss your data when it's gone. Use your restore plan.

[Citations Needed] :)

FreeText (talk) 20:01, 5 March 2014 (UTC)FreeText

Concerning the recent image change

I've reverted the image change because it's not an improvement to the article. For one thing, a device with three of four different Linux distros installed is extremely atypical, and this change seems like it was made just because the image's creator wants to insert his images into as many articles as possible, something the editor has a pattern of doing. This image isn't an improvement, and represents a very atypical situation for using GParted. - Aoidh (talk) 00:51, 27 July 2014 (UTC)

isohybrid

Gnome disks and GParted showing the identical isohybrid disk.

When Linux distributions, such as e.g. Debian or Fedora, want to offer one single file that anybody interested can download, then subsequently write to either some optical media or a USB stick, and then successfully boot either via BIOS or via UEFI, they build an isohybrid…:

• while DVD and Blu-ray support Universal Disk Format, CD-ROM support solely ISO 9660.
• booting from a CD requires ISO_9660#El_Torito
• booting via BIOS requires MBR + boot loader
• booting via UEFI requires GPT + EFI boot loader
  To achieve all of the above in one image-file that anybody can just dd to a USB stick, you need to botch the MBR…:
  • instead of the mandatory legacy MBR, that contains one partition, which barely covers the GPT, so that the contents thereof are protected from any non-GPT-aware disk utility programs, you write a custom MBR that is out-of-spec. The provided screenshot shows how GParted and GNOME Disks treat such a isohybrid. A screenshot of KDE Partition Manager is missing.
  • what do util-linux (fdisk sfdisk cfdisk) tell us about the underlying structure of this USB stick?
  • what does parted (which relies on libparted, as does GParted) say?
  • if we boot into GNU GRUB first, how does GRUB treat the disk structure? User:ScotXW^t@lk 10:59, 6 January 2026 (UTC)