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

236 lines
8.3 KiB
C++
Raw Normal View History

P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
/* Copyright (C) 2004 Bart
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Replace obsolete FSF postal address in copyright notices (#721565) This is part of parent bug: Bug #721455 - Obsolete info in license text on multiple modules and GNOME Goal: https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals * verify all source files to make sure they have a license and a copyright, and that both are up-to-date Bug #721565 - License text contains obsolete FSF postal address
2014-01-23 03:59:48 -07:00
* GNU General Public License for more details.
P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
*
* You should have received a copy of the GNU General Public License
Replace obsolete FSF postal address in copyright notices (#721565) This is part of parent bug: Bug #721455 - Obsolete info in license text on multiple modules and GNOME Goal: https://wiki.gnome.org/Initiatives/GnomeGoals/Proposals * verify all source files to make sure they have a license and a copyright, and that both are up-to-date Bug #721565 - License text contains obsolete FSF postal address
2014-01-23 03:59:48 -07:00
* along with this program; if not, see <http://www.gnu.org/licenses/>.
P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
*/
#include "../include/FileSystem.h"
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
#include "../include/GParted_Core.h"
P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
#include <cerrno>
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
#include <iostream>
#include <gtkmm/main.h>
Further RHEL / CentOS 5.9 compile fixes (#695279) Glib::ustring::compose() method requires glibmm >= 2.16, but RHEL / CentOS 5.9 only provides glibmm 2.12. Replace with String::ucompose() as is used everywhere else in the code. Add missing include for kill() and SIGINT declarations. Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
2013-04-14 07:23:47 -06:00
#include <signal.h>
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
#include <fcntl.h>
Connect output progress tracking callbacks inside execute_command() (#760709) All the output progress tracking callbacks for execution of ext2/3/4 and ntfs file system specific commands followed this pattern: sigc::connection c = signal_progress.connect( sigc::mem_fun( *this, &ext2::..._progress ) ); bool success = ! execute_command( ... ); c.disconnect(); return success; Instead, pass the callback slot and a flag into execute_command() and connect the callback inside. This simplifies the pattern to: return ! execute_command( ...|EXEC_PROGRESS_STDOUT, sigc::mem_fun( *this, &ext2::..._progress ) ); Note that as the progress tracking callbacks are only registered against updates to the relevant stream from the tracked commands they won't be called when the other stream is updated any more. Also note that signal_progress is a member of the FileSystem class and derived objects so lives as long as GParted is running, therefore the progress tracking callbacks need explicitly disconnecting at the end of execute_command(). However signal_update is a member of the PipeCapture class of which the output and error local variables in execute_command() are types. Therefore there is no need to explicitly disconnect the signal_update callbacks as they will be destructed along with the callback slots when they go out of scope at the end of the execute_command() method. Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-23 02:27:38 -07:00
#include <sigc++/slot.h>
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
namespace GParted
{
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
p * added detailed progressfeedback. It still needs some polishing, but is already far better then the old situation. And what's more, it's finally threadsafe :p
2006-01-19 12:15:15 -07:00
FileSystem::FileSystem()
P ). Resizing of ext2/3 works perfect now. I've even tested it on the * Again way too many chances to create a detailed entry (i'm glad i'm the only dev atm :P ). Resizing of ext2/3 works perfect now. I've even tested it on the partition holding my SG seasons =) Implemented checking of filesystems (only internally used atm). Done some overall tweaking, finetuning etc.. release 0.0.7 is getting shape.
2004-11-21 14:49:38 -07:00
{
}
wrap mount/umount/swapon/swapoff instead of implementing it ourselves * wrap mount/umount/swapon/swapoff instead of implementing it ourselves (#330641) * moved execute_command() to Utils and made the filesystems use it. All in all this decreased the size of the binary with 10% and made stuff more readable.
2006-02-15 09:05:26 -07:00
Add const qualifier to get_custom_text() member functions The function never modifies any member variables so make it a const member function. (FileSystem::get_custom_text() is a virtual function so can't be made static).
2015-05-16 02:38:22 -06:00
const Glib::ustring FileSystem::get_custom_text( CUSTOM_TEXT ttype, int index ) const
Add support for custom text strings depending on the filesystem Part 2 of 4 to provide new UUID support for NTFS. See Bug #667278 - Add support for setting UUID
2012-01-27 11:14:53 -07:00
{
return get_generic_text( ttype, index ) ;
}
const Glib::ustring FileSystem::get_generic_text( CUSTOM_TEXT ttype, int index )
{
Use custom text functions for mount/unmount and swapon/swapoff texts Part 3 of 4 to provide new UUID support for NTFS. See Bug #667278 - Add support for setting UUID
2012-01-27 12:41:31 -07:00
/*TO TRANSLATORS: these labels will be used in the partition menu */
static const Glib::ustring activate_text = _( "_Mount" ) ;
static const Glib::ustring deactivate_text = _( "_Unmount" ) ;
switch ( ttype ) {
case CTEXT_ACTIVATE_FILESYSTEM :
return index == 0 ? activate_text : "" ;
case CTEXT_DEACTIVATE_FILESYSTEM :
return index == 0 ? deactivate_text : "" ;
default :
return "" ;
}
Add support for custom text strings depending on the filesystem Part 2 of 4 to provide new UUID support for NTFS. See Bug #667278 - Add support for setting UUID
2012-01-27 11:14:53 -07:00
}
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
void FileSystem::store_exit_status( GPid pid, int status )
p * added detailed progressfeedback. It still needs some polishing, but is already far better then the old situation. And what's more, it's finally threadsafe :p
2006-01-19 12:15:15 -07:00
{
Implement shell style exit status decoding (#754684) Command exit status is a 1 byte value between 0 and 255. [1][2] However at the Unix API level the value is encoded as documented in the waitpid(2) manual page. This is true for the Glib API too. [3] This is why, for example, the comment in ext2::check_repair() reported receiving undocumented exit status 256. It was actually receiving exit status 1 encoded as per the waitpid(2) method. Add shell style exit status decoding [2] to execution of all external commands. Return value from Utils::execute_command() and FileSystem::execute_command() functions are now: 0 - 125 - Exit status from the command 126 - Error executing the command 127 - Command not found 128+N - Command terminated by signal N 255 - Unexpected waitpid(2) condition Also adjust checking of the returned statuses as necessary. [1] Advanced Bash-Scripting Guide: Appendix D. Exit Codes With Special Meanings http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/exitcodes.html [2] Quote from the bash(1) manual page: EXIT STATUS ... Exit statuses fall between 0 and 255, though as explained below, the shell may use values above 125 specially. ... ... When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status. If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126. [3] Quote from the Glib Reference Manual, Spawning Processes section, for function g_spawn_check_exit_status(): https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-check-exit-status The g_spawn_sync() and g_child_watch_add() family of APIs return an exit status for subprocesses encoded in a platform-specific way. On Unix, this is guaranteed to be in the same format waitpid() returns, ... Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-09-06 07:39:07 -06:00
exit_status = Utils::decode_wait_status( status );
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
running = false;
if (pipecount == 0) // pipes finished first
Gtk::Main::quit();
Glib::spawn_close_pid( pid );
:spawn_sync instead of popen(). also made the filesystems call * removed Execute_Command() and replaced it by execute_command(). The latter uses Glib::spawn_sync instead of popen(). also made the filesystems call execute_command rather than calling Glib::spawn_sync themselves.
2006-01-22 06:23:58 -07:00
}
Rename function relay_update Rename function to update_command_output() to better reflect that this callback updates the UI with the latest output read from the command being executed. This makes more sense knowing a future change will add a separate callback which parses the output read from the command and updates the progress bar. This function should be named update_command_progress().
2013-05-02 14:05:14 -06:00
//Callback passing the latest partial output from the external command
// to operation detail for updating in the UI
static void update_command_output( OperationDetail *operationdetail, Glib::ustring *str )
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
{
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
operationdetail->set_description( *str, FONT_ITALIC );
}
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
Add proper cancel support (#601239) 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'
2013-01-20 19:50:55 -07:00
static void cancel_command( bool force, Glib::Pid pid, bool cancel_safe )
{
if( force || cancel_safe )
kill( -pid, SIGINT );
}
static void setup_child()
{
setpgrp();
}
int FileSystem::execute_command( const Glib::ustring & command, OperationDetail & operationdetail,
Connect output progress tracking callbacks inside execute_command() (#760709) All the output progress tracking callbacks for execution of ext2/3/4 and ntfs file system specific commands followed this pattern: sigc::connection c = signal_progress.connect( sigc::mem_fun( *this, &ext2::..._progress ) ); bool success = ! execute_command( ... ); c.disconnect(); return success; Instead, pass the callback slot and a flag into execute_command() and connect the callback inside. This simplifies the pattern to: return ! execute_command( ...|EXEC_PROGRESS_STDOUT, sigc::mem_fun( *this, &ext2::..._progress ) ); Note that as the progress tracking callbacks are only registered against updates to the relevant stream from the tracked commands they won't be called when the other stream is updated any more. Also note that signal_progress is a member of the FileSystem class and derived objects so lives as long as GParted is running, therefore the progress tracking callbacks need explicitly disconnecting at the end of execute_command(). However signal_update is a member of the PipeCapture class of which the output and error local variables in execute_command() are types. Therefore there is no need to explicitly disconnect the signal_update callbacks as they will be destructed along with the callback slots when they go out of scope at the end of the execute_command() method. Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-23 02:27:38 -07:00
ExecFlags flags, StreamSlot stream_progress_slot )
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
{
Time and check nearly all file system action commands (#754684) There has been an undocumented rule that external commands displayed in the operation details, as part of file system manipulations, only get a time and check mark displayed when multiple commands are needed, and not otherwise. (GParted checks whether all commands are successful or not regardless of whether a check mark is displayed in the operation details or not). EXCEPTION 1: btrfs resize Since the following commit [1] from 2013-02-22, GParted stopped displaying the timing for the btrfs resize command in the operation details. It being part of a multi-command sequence to perform the step. This is because FileSystem::execute_command() since the commit can only check the exit status for zero / non-zero while timing and checking the command status but btrfs resize needs to consider some non-zero statuses as successful. [1] 52a2a9b00a32996921ace055e71d0e09fb33c5fe Reduce threading (#685740) EXCEPTION 2: ext2/3/4 move and copy using e2image When use of e2image was added [2] the single command steps were timed and check. [2] 86111fe12a26d23d9fc2a9e2d19281290ecaf985 Use e2image to move/copy ext[234] file systems (#721516) EXCEPTION 3: fat16/32 write label and UUID Uses Utils::execute_command() rather than FileSystem::execute_command() so can be separately changed. See the following commit for resolution of the final commands not yet timed and check mark displayed. CHANGE: Lets make a simpler rule of always displaying the time and a check mark for all external commands displayed in the operation details. However this makes several of the other single command actions need special exit status handling because zero success, non-zero failure is not correct for every case. Specifically affects resizing of reiserfs and check repair of ext2/3/4, fat16/32, jfs and reiserfs. After this change all external commands run as file system actions must follow one of these two patterns of using the EXEC_CHECK_STATUS flag or separately calling FileSystem::set_status() to register success or failure of the command: exit_status = execute_command(cmd, od, EXEC_CHECK_STATUS...); or: exit_status = execute_command(cmd, od, ...); bool success = (exit_status == 0 || exit_status == OTHER_SUCCESS_VALUE...); set_status(od, success ); Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-09-05 02:31:16 -06:00
operationdetail.add_child( OperationDetail( command, STATUS_EXECUTE, FONT_BOLD_ITALIC ) );
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
Glib::Pid pid;
// set up pipes for capture
int out, err;
// spawn external process
running = true;
try {
Glib::spawn_async_with_pipes(
Work around failure to execute commands with old glibmm (#695279) On RHEL / CentOS 5.9 GParted failed to run any external commands and instead reported the following warnings to the terminal: # src/gpartedbin ====================== libparted : 1.8.1 ====================== Failed to change to directory '' (No such file or directory) Failed to change to directory '' (No such file or directory) Failed to change to directory '' (No such file or directory) ... Utils::execute_command() and FileSystem::execute_command() passed a zero length string for the working directory to Glib::spawn_async_with_pipes() to mean don't change directory. Instead glibmm just tried to change to the directory with a zero length name. This was fixed with glibmm >= 2.21.2 released July 2009, however RHEL / CentOS 5.9 only has glibmm 2.12.10. Relevant glibmm fix: Treat empty Glib::spawn*() working dir as unset https://git.gnome.org/browse/glibmm/commit/?id=8a7805cbbe6d268e975669349beb4e82d971537d Fix by simply specifying ".", the current working directory, as the directory to change into before executing all commands. Bug #695279 - GParted doesn't compile on RHEL / CentOS 5.9
2013-04-18 10:06:37 -06:00
std::string( "." ),
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
Glib::shell_parse_argv( command ),
Glib::SPAWN_DO_NOT_REAP_CHILD | Glib::SPAWN_SEARCH_PATH,
Add proper cancel support (#601239) 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'
2013-01-20 19:50:55 -07:00
sigc::ptr_fun(setup_child),
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
&pid,
0,
&out,
&err );
} catch (Glib::SpawnError &e) {
std::cerr << e.what() << std::endl;
operationdetail.get_last_child().add_child(
OperationDetail( e.what(), STATUS_ERROR, FONT_ITALIC ) );
Implement shell style exit status decoding (#754684) Command exit status is a 1 byte value between 0 and 255. [1][2] However at the Unix API level the value is encoded as documented in the waitpid(2) manual page. This is true for the Glib API too. [3] This is why, for example, the comment in ext2::check_repair() reported receiving undocumented exit status 256. It was actually receiving exit status 1 encoded as per the waitpid(2) method. Add shell style exit status decoding [2] to execution of all external commands. Return value from Utils::execute_command() and FileSystem::execute_command() functions are now: 0 - 125 - Exit status from the command 126 - Error executing the command 127 - Command not found 128+N - Command terminated by signal N 255 - Unexpected waitpid(2) condition Also adjust checking of the returned statuses as necessary. [1] Advanced Bash-Scripting Guide: Appendix D. Exit Codes With Special Meanings http://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/exitcodes.html [2] Quote from the bash(1) manual page: EXIT STATUS ... Exit statuses fall between 0 and 255, though as explained below, the shell may use values above 125 specially. ... ... When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status. If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126. [3] Quote from the Glib Reference Manual, Spawning Processes section, for function g_spawn_check_exit_status(): https://developer.gnome.org/glib/stable/glib-Spawning-Processes.html#g-spawn-check-exit-status The g_spawn_sync() and g_child_watch_add() family of APIs return an exit status for subprocesses encoded in a platform-specific way. On Unix, this is guaranteed to be in the same format waitpid() returns, ... Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-09-06 07:39:07 -06:00
return Utils::get_failure_status( e );
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
}
fcntl( out, F_SETFL, O_NONBLOCK );
fcntl( err, F_SETFL, O_NONBLOCK );
Glib::signal_child_watch().connect( sigc::mem_fun( *this, &FileSystem::store_exit_status ), pid );
output.clear();
error.clear();
pipecount = 2;
PipeCapture outputcapture( out, output );
PipeCapture errorcapture( err, error );
Rename signals update and eof Rename the libsigc++ signals to signal_update and signal_eof to match the naming used for signals in GParted. fgrep 'sigc::signal' include/*.h Also explicitly use the emit() method rather than using the object operator(). This again is to match the convention in GParted and make it more obvious what is happening. fgrep '.emit(' include/*.h
2013-05-02 01:35:17 -06:00
outputcapture.signal_eof.connect( sigc::mem_fun( *this, &FileSystem::execute_command_eof ) );
errorcapture.signal_eof.connect( sigc::mem_fun( *this, &FileSystem::execute_command_eof ) );
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
operationdetail.get_last_child().add_child(
OperationDetail( output, STATUS_NONE, FONT_ITALIC ) );
operationdetail.get_last_child().add_child(
OperationDetail( error, STATUS_NONE, FONT_ITALIC ) );
Change OperationDetail to not store complex objects in STL containers (#729139) OperationDetail was storing its children in a std::vector. This means they can be moved around in memory arbitrarily, going through indeterminate lifetimes. This is generally a bad thing for any non trivial object and in the case of OperationDetail, it created havoc with the way it maintains pointers between parent/child objects for signal connections. It will now keep only pointers to children in a std::vector instead, so their lifetime can be controlled, fixing various crashes. Bug 729139 - Refactor OperationDetail to address random behavior
2014-04-01 20:04:01 -06:00
std::vector<OperationDetail*> &children = operationdetail.get_last_child().get_childs();
Rename function relay_update Rename function to update_command_output() to better reflect that this callback updates the UI with the latest output read from the command being executed. This makes more sense knowing a future change will add a separate callback which parses the output read from the command and updates the progress bar. This function should be named update_command_progress().
2013-05-02 14:05:14 -06:00
outputcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ),
Change OperationDetail to not store complex objects in STL containers (#729139) OperationDetail was storing its children in a std::vector. This means they can be moved around in memory arbitrarily, going through indeterminate lifetimes. This is generally a bad thing for any non trivial object and in the case of OperationDetail, it created havoc with the way it maintains pointers between parent/child objects for signal connections. It will now keep only pointers to children in a std::vector instead, so their lifetime can be controlled, fixing various crashes. Bug 729139 - Refactor OperationDetail to address random behavior
2014-04-01 20:04:01 -06:00
children[children.size() - 2],
Rename signals update and eof Rename the libsigc++ signals to signal_update and signal_eof to match the naming used for signals in GParted. fgrep 'sigc::signal' include/*.h Also explicitly use the emit() method rather than using the object operator(). This again is to match the convention in GParted and make it more obvious what is happening. fgrep '.emit(' include/*.h
2013-05-02 01:35:17 -06:00
&output ) );
Rename function relay_update Rename function to update_command_output() to better reflect that this callback updates the UI with the latest output read from the command being executed. This makes more sense knowing a future change will add a separate callback which parses the output read from the command and updates the progress bar. This function should be named update_command_progress().
2013-05-02 14:05:14 -06:00
errorcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ),
Change OperationDetail to not store complex objects in STL containers (#729139) OperationDetail was storing its children in a std::vector. This means they can be moved around in memory arbitrarily, going through indeterminate lifetimes. This is generally a bad thing for any non trivial object and in the case of OperationDetail, it created havoc with the way it maintains pointers between parent/child objects for signal connections. It will now keep only pointers to children in a std::vector instead, so their lifetime can be controlled, fixing various crashes. Bug 729139 - Refactor OperationDetail to address random behavior
2014-04-01 20:04:01 -06:00
children[children.size() - 1],
Rename signals update and eof Rename the libsigc++ signals to signal_update and signal_eof to match the naming used for signals in GParted. fgrep 'sigc::signal' include/*.h Also explicitly use the emit() method rather than using the object operator(). This again is to match the convention in GParted and make it more obvious what is happening. fgrep '.emit(' include/*.h
2013-05-02 01:35:17 -06:00
&error ) );
Connect output progress tracking callbacks inside execute_command() (#760709) All the output progress tracking callbacks for execution of ext2/3/4 and ntfs file system specific commands followed this pattern: sigc::connection c = signal_progress.connect( sigc::mem_fun( *this, &ext2::..._progress ) ); bool success = ! execute_command( ... ); c.disconnect(); return success; Instead, pass the callback slot and a flag into execute_command() and connect the callback inside. This simplifies the pattern to: return ! execute_command( ...|EXEC_PROGRESS_STDOUT, sigc::mem_fun( *this, &ext2::..._progress ) ); Note that as the progress tracking callbacks are only registered against updates to the relevant stream from the tracked commands they won't be called when the other stream is updated any more. Also note that signal_progress is a member of the FileSystem class and derived objects so lives as long as GParted is running, therefore the progress tracking callbacks need explicitly disconnecting at the end of execute_command(). However signal_update is a member of the PipeCapture class of which the output and error local variables in execute_command() are types. Therefore there is no need to explicitly disconnect the signal_update callbacks as they will be destructed along with the callback slots when they go out of scope at the end of the execute_command() method. Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-23 02:27:38 -07:00
if ( flags & EXEC_PROGRESS_STDOUT && ! stream_progress_slot.empty() )
// Call progress tracking callback when stdout updates
Remove the unnecessary signal_progress (#760709) For the relevant stream from a file system specific command being tracked, there were 2 callbacks attached: update_command_output() and update_command_progress(). When called, update_command_progress() just emitted signal_progress to call the file system specific progress tracker callback. Like this: signal_update.emit() -> update_command_output() -> update_command_progress() signal_progress.emit() -> {CLASS}::{NAME}_progress() Instead just connect the file system specific progress tracker callback directly to signal_update and bypass the unnecessary update_command_progress() method and the signal_progress signal. Like this: signal_update.emit() -> update_command_output() -> {CLASS}::{NAME}_progress() Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-29 09:36:05 -07:00
outputcapture.signal_update.connect( sigc::bind( stream_progress_slot, &operationdetail ) );
Connect output progress tracking callbacks inside execute_command() (#760709) All the output progress tracking callbacks for execution of ext2/3/4 and ntfs file system specific commands followed this pattern: sigc::connection c = signal_progress.connect( sigc::mem_fun( *this, &ext2::..._progress ) ); bool success = ! execute_command( ... ); c.disconnect(); return success; Instead, pass the callback slot and a flag into execute_command() and connect the callback inside. This simplifies the pattern to: return ! execute_command( ...|EXEC_PROGRESS_STDOUT, sigc::mem_fun( *this, &ext2::..._progress ) ); Note that as the progress tracking callbacks are only registered against updates to the relevant stream from the tracked commands they won't be called when the other stream is updated any more. Also note that signal_progress is a member of the FileSystem class and derived objects so lives as long as GParted is running, therefore the progress tracking callbacks need explicitly disconnecting at the end of execute_command(). However signal_update is a member of the PipeCapture class of which the output and error local variables in execute_command() are types. Therefore there is no need to explicitly disconnect the signal_update callbacks as they will be destructed along with the callback slots when they go out of scope at the end of the execute_command() method. Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-23 02:27:38 -07:00
else if ( flags & EXEC_PROGRESS_STDERR && ! stream_progress_slot.empty() )
// Call progress tracking callback when stderr updates
Remove the unnecessary signal_progress (#760709) For the relevant stream from a file system specific command being tracked, there were 2 callbacks attached: update_command_output() and update_command_progress(). When called, update_command_progress() just emitted signal_progress to call the file system specific progress tracker callback. Like this: signal_update.emit() -> update_command_output() -> update_command_progress() signal_progress.emit() -> {CLASS}::{NAME}_progress() Instead just connect the file system specific progress tracker callback directly to signal_update and bypass the unnecessary update_command_progress() method and the signal_progress signal. Like this: signal_update.emit() -> update_command_output() -> {CLASS}::{NAME}_progress() Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-29 09:36:05 -07:00
errorcapture.signal_update.connect( sigc::bind( stream_progress_slot, &operationdetail ) );
Avoid glibmm GSource bug/crash (again) (#697727) The previous commit missed one glibmm GSource wrapper in the form of the io watch for the PipeCapture class. Convert this one to use glib directly as well. Bug #697727 - Segfault in livecd Gparted v 0.15.0-3 when copying partition
2013-04-25 14:08:58 -06:00
outputcapture.connect_signal();
errorcapture.connect_signal();
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
Add proper cancel support (#601239) 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'
2013-01-20 19:50:55 -07:00
operationdetail.get_last_child().signal_cancel.connect(
sigc::bind(
sigc::ptr_fun( cancel_command ),
pid,
Refactor flags in method FileSystem::execute_command() (#754684) Change the two optional boolean parameters into a single optional flags parameter which uses symbolically defined names. Makes reading the execute_command() calls much easier to understand. (Implemented as bit field using the same technique as used for Glib::SpawnFlags [1]). This changes the calls thus: execute_command(cmd, od) -> (cmd, od) execute_command(cmd, od, false) -> (cmd, od, EXEC_NONE) // [2] execute_command(cmd, od, true ) -> (cmd, od, EXEC_CHECK_STATUS) execute_command(cmd, od, false, true) -> (cmd, od, EXEC_CANCEL_SAFE) execute_command(cmd, od, true , true) -> (cmd, od, EXEC_CHECK_STATUS|EXEC_CANCEL_SAFE) [1] SpawnFlags bitwise operators in /usr/include/glibmm-2.4/glibmm/spawn.h. [2] False and EXEC_NONE are the default values for the optional third parameter before and after this change respectively and both mean the same. This is being used in btrfs::resize() and being kept for now despite it being the default. Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-08-29 08:15:24 -06:00
flags & EXEC_CANCEL_SAFE ) );
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
Gtk::Main::run();
Refactor flags in method FileSystem::execute_command() (#754684) Change the two optional boolean parameters into a single optional flags parameter which uses symbolically defined names. Makes reading the execute_command() calls much easier to understand. (Implemented as bit field using the same technique as used for Glib::SpawnFlags [1]). This changes the calls thus: execute_command(cmd, od) -> (cmd, od) execute_command(cmd, od, false) -> (cmd, od, EXEC_NONE) // [2] execute_command(cmd, od, true ) -> (cmd, od, EXEC_CHECK_STATUS) execute_command(cmd, od, false, true) -> (cmd, od, EXEC_CANCEL_SAFE) execute_command(cmd, od, true , true) -> (cmd, od, EXEC_CHECK_STATUS|EXEC_CANCEL_SAFE) [1] SpawnFlags bitwise operators in /usr/include/glibmm-2.4/glibmm/spawn.h. [2] False and EXEC_NONE are the default values for the optional third parameter before and after this change respectively and both mean the same. This is being used in btrfs::resize() and being kept for now despite it being the default. Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-08-29 08:15:24 -06:00
if ( flags & EXEC_CHECK_STATUS )
{
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
if ( !exit_status )
operationdetail.get_last_child().set_status( STATUS_SUCCES );
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
else
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
operationdetail.get_last_child().set_status( STATUS_ERROR );
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
}
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
close( out );
close( err );
Connect output progress tracking callbacks inside execute_command() (#760709) All the output progress tracking callbacks for execution of ext2/3/4 and ntfs file system specific commands followed this pattern: sigc::connection c = signal_progress.connect( sigc::mem_fun( *this, &ext2::..._progress ) ); bool success = ! execute_command( ... ); c.disconnect(); return success; Instead, pass the callback slot and a flag into execute_command() and connect the callback inside. This simplifies the pattern to: return ! execute_command( ...|EXEC_PROGRESS_STDOUT, sigc::mem_fun( *this, &ext2::..._progress ) ); Note that as the progress tracking callbacks are only registered against updates to the relevant stream from the tracked commands they won't be called when the other stream is updated any more. Also note that signal_progress is a member of the FileSystem class and derived objects so lives as long as GParted is running, therefore the progress tracking callbacks need explicitly disconnecting at the end of execute_command(). However signal_update is a member of the PipeCapture class of which the output and error local variables in execute_command() are types. Therefore there is no need to explicitly disconnect the signal_update callbacks as they will be destructed along with the callback slots when they go out of scope at the end of the execute_command() method. Bug 760709 - Add progress bars to XFS and EXT2/3/4 file system specific copy methods
2016-01-23 02:27:38 -07:00
operationdetail.stop_progressbar();
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
return exit_status;
}
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
Time and check nearly all file system action commands (#754684) There has been an undocumented rule that external commands displayed in the operation details, as part of file system manipulations, only get a time and check mark displayed when multiple commands are needed, and not otherwise. (GParted checks whether all commands are successful or not regardless of whether a check mark is displayed in the operation details or not). EXCEPTION 1: btrfs resize Since the following commit [1] from 2013-02-22, GParted stopped displaying the timing for the btrfs resize command in the operation details. It being part of a multi-command sequence to perform the step. This is because FileSystem::execute_command() since the commit can only check the exit status for zero / non-zero while timing and checking the command status but btrfs resize needs to consider some non-zero statuses as successful. [1] 52a2a9b00a32996921ace055e71d0e09fb33c5fe Reduce threading (#685740) EXCEPTION 2: ext2/3/4 move and copy using e2image When use of e2image was added [2] the single command steps were timed and check. [2] 86111fe12a26d23d9fc2a9e2d19281290ecaf985 Use e2image to move/copy ext[234] file systems (#721516) EXCEPTION 3: fat16/32 write label and UUID Uses Utils::execute_command() rather than FileSystem::execute_command() so can be separately changed. See the following commit for resolution of the final commands not yet timed and check mark displayed. CHANGE: Lets make a simpler rule of always displaying the time and a check mark for all external commands displayed in the operation details. However this makes several of the other single command actions need special exit status handling because zero success, non-zero failure is not correct for every case. Specifically affects resizing of reiserfs and check repair of ext2/3/4, fat16/32, jfs and reiserfs. After this change all external commands run as file system actions must follow one of these two patterns of using the EXEC_CHECK_STATUS flag or separately calling FileSystem::set_status() to register success or failure of the command: exit_status = execute_command(cmd, od, EXEC_CHECK_STATUS...); or: exit_status = execute_command(cmd, od, ...); bool success = (exit_status == 0 || exit_status == OTHER_SUCCESS_VALUE...); set_status(od, success ); Bug 754684 - Updates to FileSystem:: and Utils::execute_command() functions
2015-09-05 02:31:16 -06:00
void FileSystem::set_status( OperationDetail & operationdetail, bool success )
{
operationdetail.get_last_child().set_status( success ? STATUS_SUCCES : STATUS_ERROR );
}
Reduce threading (#685740) 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
2013-02-21 17:57:33 -07:00
void FileSystem::execute_command_eof()
{
if (--pipecount)
return; // wait for second pipe to eof
if ( !running ) // already got exit status
Gtk::Main::quit();
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
}
//Create uniquely named temporary directory and add results to operation detail
Glib::ustring FileSystem::mk_temp_dir( const Glib::ustring & infix, OperationDetail & operationdetail )
{
// Construct template like "$TMPDIR/gparted-XXXXXX" or "$TMPDIR/gparted-INFIX-XXXXXX"
Glib::ustring dir_template = Glib::get_tmp_dir() + "/gparted-" ;
if ( ! infix .empty() )
dir_template += infix + "-" ;
dir_template += "XXXXXX" ;
//Secure Programming for Linux and Unix HOWTO, Chapter 6. Avoid Buffer Overflow
// http://tldp.org/HOWTO/Secure-Programs-HOWTO/library-c.html
char dir_buf[4096+1];
Fix mismatched field precision type compiler warning Inserted cast to int so that third parameter matches expected parameter precision type. Original warning: FileSystem.cc: In member function ‘Glib::ustring GParted::FileSystem::mk_temp_dir(const Glib::ustring&, GParted::OperationDetail&)’: FileSystem.cc:81:69: warning: field precision should have type ‘int’, but argument 3 has type ‘long unsigned int’
2012-01-12 13:07:37 -07:00
sprintf( dir_buf, "%.*s", (int) sizeof(dir_buf)-1, dir_template .c_str() ) ;
Add helper functions for mounted file system resizing operations There is a lot of commonality and code repetition for resizing of file systems which can only be resized while mounted. Resizing of btrfs, jfs and xfs all follow the pattern: mkdir, mount, resize, umount and rmdir. Copying an xfs file system also uses a similar pattern, but for the source and destination xfs file systems simultaneously. Add three helper functions to the FileSystem class which implement common tasks, allowing mounted file system resizing to be implemented more simply. Also add a function to the Utils class which checks whether the kernel supports a file system. It handles the case of non-loaded modules, which currently leads to reporting the growing of jfs and xfs as unsupported.
2011-12-27 04:05:11 -07:00
//Looks like "mkdir -v" command was run to the user
operationdetail .add_child( OperationDetail(
Glib::ustring( "mkdir -v " ) + dir_buf, STATUS_EXECUTE, FONT_BOLD_ITALIC ) ) ;
const char * dir_name = mkdtemp( dir_buf ) ;
if ( NULL == dir_name )
{
int e = errno ;
operationdetail .get_last_child() .set_status( STATUS_ERROR ) ;
operationdetail .get_last_child() .add_child( OperationDetail(
String::ucompose( "mkdtemp(%1): %2", dir_buf, Glib::strerror( e ) ), STATUS_NONE ) ) ;
dir_name = "" ;
}
else
{
//Update command with actually created temporary directory
operationdetail .get_last_child() .set_description(
Glib::ustring( "mkdir -v " ) + dir_name, FONT_BOLD_ITALIC ) ;
operationdetail .get_last_child() .set_status( STATUS_SUCCES ) ;
operationdetail .get_last_child() .add_child( OperationDetail(
/*TO TRANSLATORS: looks like Created directory /tmp/gparted-CEzvSp */
String::ucompose( _("Created directory %1"), dir_name ), STATUS_NONE ) ) ;
}
return Glib::ustring( dir_name ) ;
}
//Remove directory and add results to operation detail
void FileSystem::rm_temp_dir( const Glib::ustring dir_name, OperationDetail & operationdetail )
{
//Looks like "rmdir -v" command was run to the user
operationdetail .add_child( OperationDetail( Glib::ustring( "rmdir -v " ) + dir_name,
STATUS_EXECUTE, FONT_BOLD_ITALIC ) ) ;
if ( rmdir( dir_name .c_str() ) )
{
//Don't mark operation as errored just because rmdir
// failed. Set to Warning (N/A) instead.
int e = errno ;
operationdetail .get_last_child() .set_status( STATUS_SUCCES ) ; //Stop timer
operationdetail .get_last_child() .set_status( STATUS_N_A ) ;
operationdetail .get_last_child() .add_child( OperationDetail(
String::ucompose( "rmdir(%1): ", dir_name ) + Glib::strerror( e ), STATUS_NONE ) ) ;
}
else
{
operationdetail .get_last_child() .set_status( STATUS_SUCCES ) ;
operationdetail .get_last_child() .add_child( OperationDetail(
/*TO TRANSLATORS: looks like Removed directory /tmp/gparted-CEzvSp */
String::ucompose( _("Removed directory %1"), dir_name ), STATUS_NONE ) ) ;
}
}
P) It still needs a lot of love, but the foundations are laid =) * Rewrote a large part of gparteds internal code. Filesystemssupport is now much more separated from the rest of gparted and adding support for other filesystems should be a piece of cake now (hope that's true :P) It still needs a lot of love, but the foundations are laid =)
2004-11-17 06:00:25 -07:00
} //GParted