[parted-devel] Preparing for a "Switch" campaign
Bart Hakvoort
bart at hakvoort.be
Sat Jul 29 16:51:21 UTC 2006
One of the points in the list is:
* creating an API that enables us to call external programs in a
more or less well-defined way
In GParted i do this and the requirements are actually very little. The
hardest thing is to get decent progressfeedback while a lengthy task is
performed. I'm still working on this every now and then.
The following file defines the 'interface' which all the filesystemclasses
in GParted use:
http://cvs.gnome.org/viewcvs/gparted/include/FileSystem.h?view=markup
I guess libparted will drop the OperationDetails part, so what's actually
left is the following:
FS get_filesystem_support() ;
some kind of function to determine which tools are available...
void Set_Used_Sectors( Partition & partition ) ;
determine used/unused space..
bool Create( const Partition & new_partition) ;
create new filesystem on partition...
bool Resize( const Partition & partition_new, bool fill_partition = false );
resize partition to new size.., fill_partition is for convenience, since
all filesystemtools fill the partition when you simply call 'resizetool
<device>'. This saves you some calculating of new sizes..
bool Copy( const Glib::ustring & src_part_path,
const Glib::ustring & dest_part_path);
atm i only use this for ntfs (ntfsclone) and xfs (xfsdump tools). the rest
can be done by ped_device_read and ped_device_write..
bool Check_Repair( const Partition & partition ) ;
run a check utility on the partition.
Note that all the above stuff only works because you already created the
actual partition. This stuff only affects filesystems.
Feel free to take a look at the gparted sourcecode and contact me any time
when you have questions :)
Bart (plors)
>
> Hello everyone interested in GNU Parted and GNU fdisk,
>
> the finishing of the cfdisk program in autumn marks an excellent point
> to think about the future and talk about a concept that will enable us
> to slowly replace obsolete partitioning programs in the UNIX world.
>
> Attached to this mail is a draft of a paper which shows some reasons
> why this is a Good Thing(tm).
>
> It is important to discuss these things now since there are a lot of
> things to be done I know right now, and probably a whole lot more you
> will come up with.
>
> Getting 'libparted' ready means:
>
> * revising the documentation
> * creating an API that enables us to call external programs in a
> more or less well-defined way
> * supporting real partition IDs
> * fixing BSD support
> * testing it THOROUGHLY
>
> Getting 'parted' ready means
> * fixing the "print all" command as described in an earlier post
> to parted-devel.
> * making it support "raw" partition resizing (independent from
> the data contained)
> * removing the newly introduced "NAME" parameter from "mkpart"
> * adding a script-friendly output interface (also discussed
> earlier on parted-devel)
> * testing it THOROUGHLY
>
> Getting 'lfdisk', the replacement for Linux fdisk, ready means:
> * adapting its output to match that of its role model more
> closely
> * cleaning up the code, while possibly reusing code common
> with cfdisk
> * testing it THOROUGHLY
>
> I invite you all to partitipate in both discussion and coding,
> whatever suits you. My schedule for July is crammed (apart from the
> weekends, but I suspect that may change soon as well), but after that I
> can probably work half-time on it.
>
> Kind regards,
>
> Leslie
>
> --
> gpg --keyserver pgp.mit.edu --recv-keys 0x52D70289
> http://nic-nac-project.de/~skypher/
> _______________________________________________
> parted-devel mailing list
> parted-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/parted-devel
>
--
--- plors
More information about the parted-devel
mailing list