[parted-devel] Preparing for a "Switch" campaign

[Bart Hakvoort]

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