[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