[Kde-hardware-devel] Format application and backend features

Kevin Ottens ervin at kde.org
Mon Mar 13 17:40:39 CET 2006


Le Lundi 13 Mars 2006 01:38, Jean-Rémy Falleri a écrit :
> KFormat is expected to be able to format any kind of supported devices
> (floppy, usb stick, ...). The problem is that each medium kind does
> not have the same way to be formatted so KFormat need a way to know
> which type of format it is allowed to use with the selected device.
>
> KFormat have to handle as many filesystems (ext2, fat, ...) as
> possible, so a way to know which filesystems are actually available on
> the user system is also needed.

Well, it's not simply "on the user system", you surely want to know which 
fstypes are allowed for a particular volume (or storage? more on this below) 
for example you shouldn't format a cdrw as ext3, but you can format it for 
packet writing.

From what you're explaining, it looks like you're only wanting to format 
volumes. What happens when you have a storage device with no volume?

Moreover, the partition table needs to be updated when you reformat a vfat 
volume to ext3 (for example). Should this be updated transparently for you? 
Or it makes sense for KFormat to make all those modifications itself? (I tend 
to think that it should be handled transparently for you, but I'd like your 
opinion on this)

> To finish, KFormat needs support for formatting action inside the API,
> and if possible, it would be nice to have some signals (format
> started, format ended, error, progress) to have a good integration.

Since the hypotethical "format()" method would surely return a Job, no need 
for extra signals. Jobs already provide progress and error report. It means 
that it should be properly implemented in the underlying backend of course.

> A method used to check medium integrity would be also helpful (can be
> launched after format action to ensure that format behaved well).

Which kind of check do you imagine? Apart from checking for bad blocks while 
formatting I don't see which clever operation we could do afterward.

Regards.
-- 
Kévin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le maître sans disciple, Ni le disciple sans maître,
Ne font reculer l'ignorance."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20060313/81d464a8/attachment.pgp 


More information about the Kde-hardware-devel mailing list