Interested operations can now connect a signal to their OperationDetail
to be notified of a cancelation request. The internal copy/move code
will now cleanly stop on cancelation, allowing the partition to be
rolled back to its previous state. This makes canceling a move
perfectly safe.
After clicking cancel, the button changes to "Force Cancel" and is
disabled for 5 seconds. Operations that are safe to cancel will do so
and those that are not will continue to run. Clicking force cancel
asks operations to cancel, even if doing so is unsafe. For the
internal copy/move algorithm, canceling is always safe because an
error results in a rollback operation. Canceling the rollback is
unsafe. For external commands, filesystem modules may indicate
that the command is safe to cancel or not. Canceled commands will
be terminated with SIGINT.
As a result of the new safe cancel vs force cancel distinction, the
scary warning about cancl causing corruption has been moved to
after clicking the force cancel button.
Part of Bug #601239 - Please allow 'Cancel after current operation'
Have the copy code create a background thread to do the actual copying so
that it won't block the main loop.
Part of Bug 685740 - Refactor to use asynchronous command execution
Win_Gparted and Dialog_Progress were creating threads to perform most
functions in the background. Most of the time, the only reason the
threads blocked was to execute an external command. The external command
execution has been changed to spawn the command asynchronously and wait
for completion with a nested main loop. While waiting for completion,
the pipe output is captured via events. In the future, this will allow
for it to be parsed in real time to obtain progress information.
Those tasks in GParted_Core that still block now spawn a background thread
and wait for it to complete with a nested main loop to avoid hanging the
gui.
Part of Bug #685740 - Refactor to use asynchronous command execution
They were used like global variables. Now they are moved to the
functions that actually use them to make clearer how the data flow is.
Bug #683149 - Cleanup(?): Remove lp_device and lp_disk from GParted_Core
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
When an inactive LVM2 Volume Group is exported it makes it unknown to
the local system, ready for moving the member Physical Volumes to
another system, where the VG can be imported and used. In this state a
PV can't be resized.
# lvm pvresize /dev/sda10
Volume group Test-VG1 is exported
Unable to read volume group "Test-VG1".
0 physical volume(s) resized / 1 physical volume(s) not resized
# echo $?
5
Fix this by preventing resizing of such a PV. This has been coded in a
generic way using new function filesystem_resize_disallowed() to
determine whether a file system is allowed to be resized or not. For
a file system which can be resized, but is currently not allowed to be
resized, the behaviour is as follows:
1) Pasting into unallocated space is limited to creating a new
partition which is the same size as the copied partition.
2) Resizing the partition is disallowed, only moving the partition is
allowed.
3) Pasting into an existing partition will only copy the file system.
If the destination partition is larger a warning will report that
growing the file system is not currently allowed.
4) Checking a partition will also report a warning that growing the
file system is not currently allowed.
This is exactly the same behaviour as for a file system which does not
implement resizing, except for a different warning message.
Bug #670171 - Add LVM PV read-write support
This commit only adds a remove() method to every file system and an
optional call to it in the relevant operations. All remove() methods
are no operations and not enabled.
The remove() method provides explicit controlled removal of a file
system before the partition is deleted or overwritten by being formatted
or pasted into. When implemented, it appears as an extra step in the
relevant operation. The file system specific remove() method is
explicitly allowed to fail and stop the operations currently being
applied.
This is different to the existing erase_filesystem_signatures() which
wipes any previous file system signatures immediately before a new file
system is written to ensure there is no possibility of the partition
containing two or more different file system signatures. It never fails
or reports anything to the user.
NOTE:
Most file systems should NOT implement a remove() method as it will
prevent recovery from accidental partition deletion.
Bug #670171 - Add LVM PV read-write support
The parted-3.1 release brings back FAT16/FAT32 and HFS/HFS+ file
system resize capabilities in a new libparted fs resize library.
The following operations are again available when GParted is linked
with parted-3.1:
FAT16 - grow and shrink
FAT32 - grow and shrink
HFS - shrink
HFS+ - shrink
Note that there is a difference in how move actions are handled for
FAT16/FAT32 file systems based on parted version.
When GParted is linked with parted >= 3.0:
FAT16 - move performed internally by GParted
FAT32 - move performed internally by GParted
When GParted is linked with parted < 3.0:
FAT16 - move performed by libparted
FAT32 - move performed by libparted
Thanks goes to Jim Meyering for restoring these file system resizing
capabilities in Parted 3.1 with a new libparted fs resize library.
Closes Bug #668281 - minimal file-system resize API? (FAT and HFS*
only)
Add the ability to set a new random UUID on file systems that provide
the appropriate tools to perform this action.
Update the help manual to include this new functionality. Also add
reference links to "setting a partition label" and "changing a
partition UUID" in the "copying and pasting a partition" section.
This patch does not include setting the UUID on an NTFS file system.
Bug #667278 - Add support for setting UUID
Bug #608308 - fix documentation - Copying and Pasting a Partition
We used to just log libparted exceptions without handling them. This patch
changes the exception handler to display a modal dialog box and return the
chosen action to libparted.
The release of (lib)parted 3.0 includes a change to the Application
Programing Interface - API. Most importantly, libparted 3.0 removes
many file system specific function calls, and hence the capabilities
provided by these functions. In order for GParted to compile and link
with libparted 3.0, this libparted functionality is lost.
Specifically, the functionality that is lost when GParted is compiled
and linked with libparted 3.0 is as follows:
- Loss of ability to grow and shrink FAT16 and FAT32 file systems
- Loss of ability to shrink HFS and HFS+ file systems
- Loss of ability to determine used and unused sectors in HFS and
HFS+ file systems
- Loss of ability to erase file system signatures on partition
create and format
It is hoped that other free software projects will include some or all
of the above lost functionality, which can then be added back to
GParted.
This commit includes a change in how FAT16 and FAT32 file systems are
moved. Specifically the move is now performed internally by GParted
when linked with libparted 3.0. The move functionality is provided by
libparted for prior libparted versions (e.g. less than 3.0).
This is the final enhancement in a series of commits that enable
GParted to compile with libparted version 3.0.
Closes Bug #651559 - Doesn't compile against parted 3.0
This reason for refactoring is to simplify the large GParted_Core
class, to help minimize disk reads, and to group the logic for
processing the file /proc/partitions into a single logical class.
Make align to MiB the default setting instead of align to cylinder.
Migrate logic for alignment to cylinder into its own method
snap_to_cylinder, and place common logic in snap_to_alignment.
Add alignment checks for situations where space is needed for Master
Boot Record or Extended Boot Record.
Adjust ranges on spin buttons according to required boot record space.
Copy fix for off by one sector (#596552) from
Dialog_Partition_New::Get_New_Partition to
Dialog_Base_Partition::Get_New_Partition
Enhance resize / move logic for checking locations of nearby logical
partitions to not depend on the partition ordering.
Note: This commit does not include limiting graphic movement according
to required boot record space.
Restore copyright entries by original author to those of his last
known repository commit titled "released gparted-0.3.4 on
LarryT's request." on Feb 25, 2007.
Add my own copyright entries for files in which I changed source
code. Files in which I only made spelling changes do not have my
copyright entry added.
* added support for reading volumelabels. Atm we only read ext2/3, but
the infrastructure for adding the other filesystems is in place.
It's simply a matter of finding the right commands and parsing the
output. (see #338528 for more info)
* src/Dialog_Progress.cc: make sure progressfraction stays between 0.0
and 1.0
* include/GParted_Core.h,
src/GParted_Core.cc: implemented rollback in case of failed move of
overlapping filesystems. Together with the readonly test moving
should be quite save now :)
* include/GParted_Core.h,
src/GParted_Core.cc: declared char * buf global, so it can be
initialized in copy_blocks(). This is a lot more efficient than
initializing it on every copy_block()
* include/Partition.h,
src/Partition.cc: added test_overlap()
* include/GParted_Core.h,
src/GParted_Core.cc: perform a readonly testrun before the actual
move if destination overlaps source.
* include/GParted_Core.h,
src/GParted_Core.cc: update ntfsbootsector after first sector has
changed. This is necessary to let windows boot correctly afterwards.
* src/ntfs.cc: added FIXME
* include/GParted_Core.h,
src/GParted_Core.cc: tried to fix a couple of errors with moving to
the right with overlap (thanks Larry for hunting ;) )
Although everything seems to work well i'm still not sure if
everything is 100% ok.
I guess everything could use some more testing, which is exactly
what i plan to do this weekend :)
* happy 24th birthday Johannes! :^)
* include/GParted_Core.h,
src/GParted_Core.cc: restructured resize_move() to be more robust.
This will hopefully tackle a couple of issues which came up during
the public testing.
* include/GParted_Core.h,
src/GParted_Core.cc: fixed some issues with combi move+shrink on
fat* and hfs* filesystems.
Also call wait_for_node() from commit() if 'node' was provided.
* include/GParted_Core.h,
src/GParted_Core.cc: created set_progress_info() (i actually planned
on adding some time remaining stuff, but xfiles is waiting ;) )
* include/GParted_Core.h,
src/GParted_Core.cc: did some work on disabling of automounting of
removable drives. The current method is not entirely to my liking
but it seems to work.
* implemented some stuff to find a good blocksize to use for
copy/move. Actually i'm not really happy with it, because probing
seems suboptimal, but it's better than nothing. As soon as i have
some time i should do some research on the subject to find a better
solution.
Phillip Susi