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.
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.
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.
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.
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.
You editorialized the title. We don't do that here. Please stop doing that. The scare quotes around "improvements" were particularly uncalled for. There was obviously a neutral way to word this story beyond "Release notes for GParted 0.9.0".
You could, if you were so inclined, fix the title now. "GParted 0.9.0 loses ability to resides FAT filesystems" might work.
PS: Sorry, YC disallows me from editing the title at this point of time. If anyone reading this has the administrative powers to do that, please go ahead.
I'm sorry for piling on, but the thing to do then is to do some research on the topic before submitting it. A few minutes of googling and looking at forums and change-logs should help give you an idea.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
So there's a problem with HFS on newer hardware, and the resulting decision is to completely yank all filesystem functionality?
The FAT code works, why yank it? The NTFS code works, why yank it?
This is a serious question. What possible usage does one have for gparted/libparted over something like fdisk now? 99.99% of my use case (and other's use case, if looking over various forums means anything) was resizing of partitions to install some some *ix.
My point wasn't really about HFS. All the filesystem-specific code will need to be adapted to changes in both hardware and in the target filesystems. What's going on here should make you question whether you really want to use gparted to resize partitions on new disks going forward. For my part, if a disk utility claims to work with my hardware, then it had better be tight.
My advice to you is to stick with the older versions of gparted.
All code has assumptions. As the rest of the software stack and hardware change, system software often needs to change with it to remain correct. With no active maintainer, "works" is a question, not a given.
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.
So run it on a VM/throwaway machine. Once you achieve that level of paranoia it's really turtles all the way down. Next we'll be trying to get rid of e2tools...
A properly malicious filesystem will get you a compromised userspace program... big whoop, there are far far far more likely vectors for that, at least manipulating a strange and untrusted filesystem with gparted is something you have to try to do. The danger libguestfs is attempting to avoid does not apply here meaningfully.
I know it sucks having functionality you depend on be deprecated away. I don't have a good answer for that. What alternatives are there for managing FAT, VFS, or HFS?
Edit: sorry, not vfs. I was thing vfat, but that's not really relevant either.
I don't really know. I haven't had to use it or anything else to preform those sorts of tasks for years to be honest. I just let Fedora (or whatever) format whatever disk I'm installing on as it likes. Of course I expect my usage is not typical, I also have a rather low amount of data that I keep around (below 15GB) so it's not really like I have complex disk needs. So this parted nonsense doesn't actually effect me, looking from the outside I just think it's dumb as hell.
I expect FAT/VFS/HFS/etc have an equivalent of e2tools. I never really used those FSs anyway.
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.
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?
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.
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.
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