Mirrors
/
gparted
mirror of https://gitlab.gnome.org/GNOME/gparted.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

FIXME business only snap to cylinder if operation is != DELETE or FORMAT 

* src/GParted_Core.cc: FIXME business
* src/Win_GParted.cc: only snap to cylinder if operation is != DELETE
  or FORMAT
This commit is contained in:
Bart Hakvoort 2006-07-20 20:03:54 +00:00
parent dc883ee652
commit 59dad3ec04
3 changed files with 14 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ChangeLog
View File

@ -1,3 +1,9 @@
2006-07-20 Bart Hakvoort <hakvoort@cvs.gnome.org>
* src/GParted_Core.cc: FIXME business
* src/Win_GParted.cc: only snap to cylinder if operation is != DELETE
or FORMAT
2006-07-20 Bart Hakvoort <hakvoort@cvs.gnome.org> 2006-07-20 Bart Hakvoort <hakvoort@cvs.gnome.org>
* include/GParted_Core.h, * include/GParted_Core.h,

10
src/GParted_Core.cc
View File

@ -1084,8 +1084,6 @@ bool GParted_Core::move( const Device & device,
Partition & partition_new, Partition & partition_new,
std::vector<OperationDetails> & operation_details ) std::vector<OperationDetails> & operation_details )
{ {
//FIXME: sometimes (e.g. when moving a 8mib partition) we get a shrink to 0 because somewhere (i guess in the fsclasses) the newsize is calculated as size - cylsize...
//take a look at this and see at which level this should be solved.
if ( partition_new .get_length() > partition_old .get_length() ) if ( partition_new .get_length() > partition_old .get_length() )
{ {
//first do the move //first do the move
@ -1344,7 +1342,10 @@ bool GParted_Core::resize( const Device & device,
return resize_move_partition( partition_old, partition_new, false, operation_details ) ; return resize_move_partition( partition_old, partition_new, false, operation_details ) ;
bool succes = false ; bool succes = false ;
//FIXME, i don't think this is valid anymore now we have filesystems (hfs and hfs+ e.g.) which do a move through GPARTED
//and a shrink through LIBPARTED...
//how about (fake)decoupling partition and resize through libparted by simply doing it twice?
//it would hardly do anything to performance and it would greatly improve consitency in the core.
//resize using libparted.. //resize using libparted..
if ( get_fs( partition_old .filesystem ) .grow == GParted::FS::LIBPARTED || if ( get_fs( partition_old .filesystem ) .grow == GParted::FS::LIBPARTED ||
get_fs( partition_old .filesystem ) .shrink == GParted::FS::LIBPARTED || get_fs( partition_old .filesystem ) .shrink == GParted::FS::LIBPARTED ||
@ -1374,7 +1375,8 @@ bool GParted_Core::resize( const Device & device,
succes = resize_move_partition( succes = resize_move_partition(
partition_old, partition_old,
partition_new, partition_new,
! get_fs( partition_new .filesystem ) .move,//FIXME: is this still valid? get_fs( partition_new .filesystem ) .move,//FIXME, still not sure about this one
//see other FIXME's in this function.
operation_details ) ; operation_details ) ;
//these 3 are always executed, however, if 1 of them fails the whole operation fails //these 3 are always executed, however, if 1 of them fails the whole operation fails

1
src/Win_GParted.cc
View File

@ -620,6 +620,7 @@ void Win_GParted::Add_Operation( OperationType operationtype,
{ {
Glib::ustring error ; Glib::ustring error ;
if ( operation ->type == GParted::DELETE || if ( operation ->type == GParted::DELETE ||
operation ->type == GParted::FORMAT ||
gparted_core .snap_to_cylinder( operation ->device, operation ->partition_new, error ) ) gparted_core .snap_to_cylinder( operation ->device, operation ->partition_new, error ) )
{ {
operation ->create_description() ; operation ->create_description() ;