GParted: core features lost due to parted's "improvements" in v3.0

http://git.gnome.org/browse/gparted/tree/NEWS?id=16e2cb1b23c96d6a046e4a4001a05fcad8f7d253

by bigfoot • 15 years ago

78 41 15 years ago

git.gnome.org

bigfoot6• 15 years ago

I don't get why these libparted features were "deprecated" when their removal leads to GParted 0.9.0 effectively dropping FAT16/FAT32 and HFS(+) support.

fluidcruft• 15 years ago

I guess what's missing is any indication that libparted does not intend to reimplement these features in the future in another manner? I mean it reads to me that gparted is announcing the ability to even use libparted-3.0. I mean there's a reason the libparted people bumped the version number to 3.0 (i.e. freedom to re-design the API), you know.

adestefan• 15 years ago

It looks like the same support for all file systems was removed from libparted. According to the release notes:

  Changes in behavior

  Remove all FS-related (file system-related) sub-commands; these commands
  are no longer recognized because they were all dependent on parted "knowing"
  too much about file system: mkpartfs, mkfs, cp, move, check, resize.
  This change removes not just the user interface bits, but also the
  library functions and nearly all of the underlying FS-munging code.
  The code embedded in Parted by which it knew about those file systems
  was so old, unmaintainable and buggy that while seemingly drastic,
  this change is like removing a gangrenous toe.

xilun02• 15 years ago

That is a little sad because the FS code was once the whole point of Parted. But that does not mean the removal was not justified, I don't know, I've been away from Parted for a very long time.

(disclaimer: I wrote the HFS/HFS+ code.)

click170• 15 years ago

I hope people were running into a lot of bugs and errors as a result of that code in order to get it removed...

Removing code because it's "old" or unmaintainable but which relied on features require seems like a questionable decision to me.

nate_meurer5• 15 years ago

Bug rate isn't the only consideration when deciding when to trim a code base. It's usually not even the best one.

Gparted isn't a game. It's a critical filesystem utility. Code that isn't maintainable is by definition vulnerable in terms of both security and functionality.

hasenj• 15 years ago

You've got it backwards. It's a big mistake to wait for lots of errors (which in reality means people losing their precious data) before taking this measure.

throwaway32• 15 years ago

How exactly is parted/libparted useful after this change? It now appears to do nothing above and beyond fdisk.

ominous_prime• 15 years ago

The main feature is that parted can deal with GUID Partition Tables, which are required for partition larger than 2TB.

rwmj4• 15 years ago

The code was removed because it was old, bitrotted and potentially dangerous. You really don't want to use old unmaintained code to resize your precious filesystem data.

In any case there are better ways to do this. I have an interest in this, having developed libguestfs[1] and virt-resize[2]. But I'd say that even if you don't use libguestfs, you must use the latest upstream kernel code and tools (as libguestfs does) because that's the code that will not corrupt your data.

[1] http://libguestfs.org

[2] http://libguestfs.org/virt-resize.1.html

bigfoot6• 15 years ago

I fully agree. Hopefully libguestfs support will be added to GParted soon; as changing the partition layout and resizing the file systems within these partitions is usually a hand-in-hand process, it should be controllable from a single tool.

bigfoot6• 15 years ago

Unfortunately, as I understand it, the tools accompanying libguestfs aren't capable of resizing a file system in-place -- a major downside compared to what libparted could do, as you don't necessarily have a spare hard disk in your servers.

tptacek3• 15 years ago

The title of this story is especially annoying, then. Why did 'bigfoot try to bait us?

bigfoot6• 15 years ago

Because the only thing I knew up to now was: a) libparted moved to v3.0 and removed lots of filesystem specific code, and b) as a consequence, gparted cannot deal with lots of filesystems anymore since v0.9.0 (when linked to libparted 3.0).

These are the facts available to me, I wasn't trying to bait anyone. I found it of common interest that in a year or so, when these parted/gparted versions arrive in the major distributions, you won't be able to do certain things with GParted you used to do, like resizing a FAT32 partition.

kronusaturn• 15 years ago

It's unfortunate that due to lack of communication most users of gparted will have no idea why this "killer feature" has just disappeared after an upgrade.

bcl• 15 years ago

I am the parted maintainer for Fedora. I also help with upstream a bit (I removed the CHS asserts for example). These are my own opinions:

These 'features' were removed because they were old, not well maintained, and don't fit into the core feature set of parted. You are better off relying on dedicated tools to do your filesystem specific operations.

e1ven• 15 years ago

Perhaps I am better off using dedicated tools, but this was the only feature that made Gparted useful to me at all.

I can already resize partitions manually with fdisk; What I liked was being able to resize the partitions, grow the FS to match, and write it all to disk easily.

sciurus• 15 years ago

Just because libparted removed that functionality doesn't mean gparted has to remove it. I think gparted already uses a number of fileystem-specific tools; on Ubuntu 11.04 it depends on xfsprogs, reiserfsprogs, reiser4progs, jfsutils, ntfsprogs, and dosfstools. The only problem I can see is if libparted removed functionality that no other free software tools provides.

FlowerPower• 15 years ago

Back to cfdisk and mkfs.lol then.

cookiecaper• 15 years ago

I don't see why this should be an unsurmountable thing for GParted to implement. If Parted is removing the code because it's unmaintained and crufty, someone else has a well-maintained tool for the same thing. Why can't GParted call mkfs.x? Parted still resizes partitions, after all...

I think the blame is more to be laid upon GParted than Parted; Parted seems to be going about their business normally, and GParted is apparently sticking to a philosophy of strict adherence to libparted without any additional dependencies?

GParted: core features lost due to parted's "improvements" in v3.0

Related Stories