Curtis Gedak wrote: > Jim Meyering wrote: >> Curtis Gedak wrote: >> >>> GParted uses the library libparted when resizing FAT16/32 file systems. >>> >> >> Good. Then I will remove the command-line "resize" option >> and merely leave the library code. >> > Hi Jim,
Hi Curtis, > After some more thinking (and researching), I believe a better > solution is available. My thoughts are that is better to keep the > file system specific tools together similar to what has been done with > with e2fsprogs. In this case dosfstools might have a new fatresize > command added to the package. > > To get to this state the following steps might be taken: > > 1) Create a fatresize command > > This would involve extracting the FAT16/32 file system resizing code > from parted and creating a stand alone command. As you pointed out > earlier, there is a fatresize project on SourceForge that appears to > have done this already. This project has seen recent development > activity as seen in this link: > > http://fatresize.git.sourceforge.net/git/gitweb.cgi?p=fatresize/fatresize;a=summary > > Perhaps the fatresize project team might be contacted to confirm if > their intent is to continue maintaining a stand alone fatresize > command _IF_ the FAT resizing code is removed from the parted project. That would be a great solution. I'd appreciate it if you would contact them and ask about it. > 2) Remove the FAT16/32 file system resizing code from the parted project > > This would clean up the parted code to better align with the parted > project vision (which I believe is to focus on partition editing, and > to move away from file system manipulation). > > My concern with removing the resize command from parted, but leaving > the resizing code accessible to the parted library, is that it would > make it more difficult to maintain this code. An hour ago, I posted a 4-change-set series that started with this comment: [Unfortunately, it's big enough that it requires moderator approval] Subject: planned UI removals Date: Fri, 18 Sep 2009 17:33:51 +0200 Here's the start of the UI removals I mentioned recently. It removes all FS-aware sub-commands except resize. We have to retain resize at least for FAT16/32, since there seems to be no other unix-oriented tool that can do that. I'm leaving the resize command in the UI to ease shell-based testing. This series isn't complete, since it still allows resizing of file systems of types other than FAT16/32. That's next. I'll add a few tests of resizing, along the way. I'll push these or something close on Monday. > The parted project includes many tests to exercise the code, which I > heartily applaud. Removing the command line resize command would make > it more difficult to exercise the library resize code. > > > 3) Include the fatresize command with the dosfstools project/package. > > Recently there has been some activity with the dosfstools package as > can be seen in the following link: > > http://www.daniel-baumann.ch/software/dosfstools/ > > Perhaps the current maintainer of the dosfstools package could be > contacted to consider including the fatresize command in the > dosfstools package. > > > In conclusion I think a better long term solution would be migrate the > FAT resize code out of the parted project into it's own project. To I agree completely. > do this successfully will require that someone is committed to > maintaining the fatresize command after the functionality is removed > from parted. We can hope that this is already happening. :-) _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
