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

221 lines
7.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
* GNU Library General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*/
#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>
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 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
const Glib::ustring FileSystem::get_custom_text( CUSTOM_TEXT ttype, int index )
{
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
{
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
exit_status = status;
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
}
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
static void relay_update( 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,
bool checkstatus, bool 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
{
operationdetail .add_child( OperationDetail( command, checkstatus ? STATUS_EXECUTE : STATUS_NONE, FONT_BOLD_ITALIC ) ) ;
Glib::Pid pid;
// set up pipes for capture
int out, err;
// spawn external process
running = true;
try {
Glib::spawn_async_with_pipes(
std::string(),
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 ) );
return 1;
}
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 );
outputcapture.eof.connect( sigc::mem_fun( *this, &FileSystem::execute_command_eof ) );
errorcapture.eof.connect( sigc::mem_fun( *this, &FileSystem::execute_command_eof ) );
operationdetail.get_last_child().add_child(
OperationDetail( output, STATUS_NONE, FONT_ITALIC ) );
operationdetail.get_last_child().add_child(
OperationDetail( error, STATUS_NONE, FONT_ITALIC ) );
std::vector<OperationDetail> &children = operationdetail.get_last_child().get_childs();
outputcapture.update.connect( sigc::bind( sigc::ptr_fun( relay_update ),
&(children[children.size() - 2]),
&output ) );
errorcapture.update.connect( sigc::bind( sigc::ptr_fun( relay_update ),
&(children[children.size() - 1]),
&error ) );
outputcapture.connect_signal( out );
errorcapture.connect_signal( err );
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,
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();
if (checkstatus) {
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 );
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
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