
GParted: core features lost due to parted's "improvements" in v3.0 - bigfoot
http://git.gnome.org/browse/gparted/tree/NEWS?id=16e2cb1b23c96d6a046e4a4001a05fcad8f7d253
======
rwmj
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>

~~~
bigfoot
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.

~~~
bigfoot
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
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.

------
bcl
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
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
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.

------
adestefan
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.

~~~
click170
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
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
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.

~~~
nate_meurer
It's not filesystem code. It's a userland utility that has direct access to
your devices. No, the security of utilities that can directly IO my disks is
never the least of my worries.

> "Having used gparted extensively and not having a single problem among
> hundreds of filesystem resizes..."

Cool, just make sure you stick with your legacy hardware. Tell you what, go
look at the gparted code, and tell me how it'll handle an HFS on my new 4k
sector disks. If you can either reassure me or suggest a patch, I might change
my mind.

Edit: I certainly don't mean this to insult any of the work of gparted's devs.
I just picked HFS as an example. The fact that gparted works so well is a
tribute to those developers (looking at you xilun0).

~~~
xilun0
IIRC Os X can now resize its own FS, so we can probably let my beautiful (just
kidding) HFS code RIP. I won't talk for the other FS code, I have no special
knowledge of them.

I have had no involvement in Parted for years (i'm doing radically different
things), but as the one who wrote the HFS shrinking code I think and can
explain my opinion on the subject. In summary it's a good idea to remove FS
code if it has unknown status because the environment changed, and nobody is
there to check every details.

Data security is to be taken very seriously in that kind of tool, and getting
confident enough that a good level was achieved was actually what took most of
the time when i wrote the hfs shrinker (I even unplugged the computer tens of
times while resizing, then checked that the whole content of all files on the
whole fs did not changed, then checked that OS X still booted and worked
properly, + checked some internal metadata field of the FS, and so over). A
correct review + tests in the modern context would take a lot of time, and I
don't know if somebody have it but I haven't had in the last few years, still
don't have, plus I don't even have the needed hardware anymore, so nobody
should count on me.

Also one would have to check that the HFS+/HFSX has not evolved and implement
support for interesting additional features Apple could have introduced in
recent years.

That makes me a little nostalgic, but I 100% agree that without a careful
review it is better to remove it (people who know what they are doing can
still use an older version of the software, it's free software after all) than
leave that kind of code that is now having an unknown status since the context
of the environment has changed.

Of course that opinion is only relevant for the HFS code. I know nearly
nothing about the other parts.

~~~
nate_meurer
I am at this very moment working with 4k support in filesystem code, and it is
a royal pain. You're quite right about the testing. My development on this is
turning out to be largely test-driven.

Much respect to you for your gparted work.

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

------
bigfoot
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
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.

