6 ms·

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

78 points by bigfoot 15y ago

bigfoot 15y 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 15y 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 15y 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.
- xilun0 15y 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 15y 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_meurer 15y 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.
    - Karunamon 15y ago
      It's bloody filesystem code! If someone has enough access to your system in order to invoke a partition editor on the local machine, security is the least of your worries. Functionality.. eh. Having used gparted extensively and not having a single problem among hundreds of filesystem resizes, I've got to thank the maintainers for finally forcing me to get off my ass and purchase a commercial solution that can be trusted to not have critical functionality yanked. So thanks for that.
      - rwmj 15y ago
        You are wrong. Security very much is a concern. It's a concern because you may use parted/gparted on an untrusted virtual machine or a USB key. You don't want a malformed filesystem controlled by someone you don't mutually trust to subvert a tool running as root on your host. libvirt[1] and libguestfs[2] specifically take steps to reduce the exposure. Parted did not, but it's now somewhat more secure for getting rid of features that are better done by another means. [1] https://rwmj.wordpress.com/2011/05/24/what-is-svirt/ https://rwmj.wordpress.com/2011/05/24/what-is-svirt/ [2] http://libguestfs.org/guestfs.3.html#security http://libguestfs.org/guestfs.3.html#security
        burgerbrain 15y ago
- throwaway32 15y ago
  How exactly is parted/libparted useful after this change? It now appears to do nothing above and beyond fdisk.
  - ominous_prime 15y ago
    The main feature is that parted can deal with GUID Partition Tables, which are required for partition larger than 2TB.
rwmj 15y 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 http://libguestfs.org [2] http://libguestfs.org/virt-resize.1.html http://libguestfs.org/virt-resize.1.html
- bigfoot 15y 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.
  - deleted 15y ago
    [deleted]
  - bigfoot 15y 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.
    - rwmj 15y ago
      This is true, but really gparted doesn't need to use libparted (or libguestfs) at all for resizing. It should just call out to the native tools like resize2fs or ntfsresize. That's all that libguestfs is doing underneath the covers. While obviously gparted folk have got a bit of development work to do, which you can argue was made necessary by changes in libparted, really they should have taken a close look at all that crufty filesystem code in libparted, run a mile, and used the native tools a long time ago.
- 15y ago
bcl 15y 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 15y 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 15y 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 15y ago
  Back to cfdisk and mkfs.lol then.
cookiecaper 15y 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?

78 points by bigfoot 15y 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 15y 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 15y 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.

xilun0 15y 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 15y 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_meurer 15y 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.
  - Karunamon 15y ago
    It's bloody filesystem code! If someone has enough access to your system in order to invoke a partition editor on the local machine, security is the least of your worries. Functionality.. eh. Having used gparted extensively and not having a single problem among hundreds of filesystem resizes, I've got to thank the maintainers for finally forcing me to get off my ass and purchase a commercial solution that can be trusted to not have critical functionality yanked. So thanks for that.
    - rwmj 15y ago
      You are wrong. Security very much is a concern. It's a concern because you may use parted/gparted on an untrusted virtual machine or a USB key. You don't want a malformed filesystem controlled by someone you don't mutually trust to subvert a tool running as root on your host. libvirt[1] and libguestfs[2] specifically take steps to reduce the exposure. Parted did not, but it's now somewhat more secure for getting rid of features that are better done by another means. [1] https://rwmj.wordpress.com/2011/05/24/what-is-svirt/ https://rwmj.wordpress.com/2011/05/24/what-is-svirt/ [2] http://libguestfs.org/guestfs.3.html#security http://libguestfs.org/guestfs.3.html#security
      - burgerbrain 15y ago
throwaway32 15y ago
How exactly is parted/libparted useful after this change? It now appears to do nothing above and beyond fdisk.
- ominous_prime 15y ago
  The main feature is that parted can deal with GUID Partition Tables, which are required for partition larger than 2TB.

rwmj 15y 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 http://libguestfs.org [2] http://libguestfs.org/virt-resize.1.html http://libguestfs.org/virt-resize.1.html

bigfoot 15y 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.
- deleted 15y ago
  [deleted]
- bigfoot 15y 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.
  - rwmj 15y ago
    This is true, but really gparted doesn't need to use libparted (or libguestfs) at all for resizing. It should just call out to the native tools like resize2fs or ntfsresize. That's all that libguestfs is doing underneath the covers. While obviously gparted folk have got a bit of development work to do, which you can argue was made necessary by changes in libparted, really they should have taken a close look at all that crufty filesystem code in libparted, run a mile, and used the native tools a long time ago.
15y ago

bcl 15y 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 15y 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 15y 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 15y ago
Back to cfdisk and mkfs.lol then.

cookiecaper 15y 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?