Jim Meyering wrote:
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.
I will look into contacting the fatresize project regarding this question.
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.
I think it is a good idea to keep the resize FAT16/32 file system code
in parted for at least a while longer (perhaps even up to a year or
more). That way it will provide some overlap time between when the
fatresize project contains the updated code from parted, and when
dosfstools might include the fatresize command. This will also provide
various distributions time to include such code in the respective
updated packages.
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
