[parted-devel] next to master; making a beta release soon; plans

[Jim Meyering]

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.  :-)