GNOME Bugzilla – Bug 467925
gparted: add progress bar during operation
Last modified: 2016-01-18 17:44:18 UTC
Checking/resizing can be very long operation. It would be pleasant if it is possible to see the progress of these operations. The 'details' view only provides the command running. However, e2fsck and resize2fs have support for progress bar. If gparted can use them, it would be great. The progress is correctly shown for the 'move' operation : the first bar of the 'applying pending operation' dialog grow from 0% to 100%. The same thing for checking and resizing would be great. Original Debian Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432141
*** Bug 572783 has been marked as a duplicate of this bug. ***
*** Bug 589713 has been marked as a duplicate of this bug. ***
This is a problem for Ubuntu users as well: https://bugs.launchpad.net/gparted/+bug/295337 " When running partition check in GParted (Hardy) on my 1.5TB disk partition, it takes about 3 hours to complete and all the time I can see only "0 of 1 operations completed". It would be nice to see % number of that operation. User cannot guess if it would take minutes, hours or days. "
Personally I'd be fine with just seeing stdout of the e2fsck or whatever it is that's taking so long. Even if that wouldn't always tell me how much time is left, it at least does tell me that something is still happening.
I agree that having some indication of progress is very important. Has there been any movement on this issue? I am using the new rescue option on a 1.5TB USB HDD. I have no idea how long this will take or even if it is working at all. I'm stuck on a message stating 'Searching for file systems', with the bar bouncing back and forth for several hours now. As Johan says, it doesn't have to be a bar, just any indication that we can be sure that work is being done. Thanks
I'm doing a search-for-file-systems operation on a 2tb drive. It has been running for almost 12 hours. Having never done this before I really have no idea whether it might take the rest of the week, also whether it is likely to survive sleep/wake cycles for several days in a row. Yes, a progress indication would be "pleasant" ;) I guess the shuttle is at least encouraging, i.e something is probably actually happening, Gpartedbin and gpart are each using about 7% of the cpu, on the very nice on-the-desktop process list (Parted Magic), which I guess is also encouraging. I see Owen's comment is very similar. So for now I can only offer more encouragement. If you have an offset available from the underlying utility you could use that to display a moving current position indicator right on the existing linear graphic representing the disk. That might be tricky to design right (graphically) but might also be more helpful in evaluating the nature of the progress through a disk on which ostensible partitions are already visible even if not functioning or mountable. It might in some cases give someone enough information to know when to give up.
I also stack without progress bar on resizing partition. Big question appears: kill it or not to kill it. :) Top only show ~ 100% usage by resize2fs process. I have lucky and while reading this post everything goes fine and gparted jumps to moving data where progress bar is. Gparted NEEDs to ADD A indication of resizing progress.
Created attachment 242183 [details] [review] 0001-Display-progress-during-resize-467925.patch
Created attachment 242184 [details] [review] 0002-Display-progress-for-mke2fs-467925.patch
Created attachment 242185 [details] [review] 0003-Display-progress-for-e2fsck-467925.patch
Created attachment 243098 [details] [review] GParted renames (v1) Hi Curtis and Phillip, I'd like to rename a few identifiers related to capturing command output for the purpose of improving consistency and readability and therefore code maintainability. I'd like these renames to be applied ahead of Phillip's patches in this bug report if that's OK. I've done an initial review of Phillip's patches and they look pretty good. Definitely better than just enabling updating command output I did in bug #697662 "Do not hide the progress of the tools used". Before we close that as a duplicate though I would like Phillip's patches here committed and then we can review if of the other pseudo type progress information can be processed to produce progress bars too. Thanks, Mike P.S. Phillip you can upload multiple git patches as a single file. If you require the git command line see http://www.gparted.org/git.php for details.
Thank you Mike for discovering some inconsistency in the class and method names and creating a patch to bring the names more in line with the rest of GParted. The changes in comment #11 look good to me and should help increase readability and hence maintainability of the code. Phillip, Do you have any further suggestions on the patch in comment #11 to improve naming consistency? If not, then I will commit the patch in comment #11. Following that we can look at the patches in comments 8, 9, and 10.
Created attachment 243381 [details] [review] GParted renames (v2) Hi, I've been through both sets of patches again looking at the signals and callbacks and as a result I have my updated my patchset slightly. The only change from "GParted renames (v1)" is to update the naming of callback functions in patch number 3. After my patchset and Phillip's I would like to see the following names used for Signals and callbacks: PipeCapture::signal_update -------------------------- connected in FileSystem::execute_command() outputcapture.signal_update -> (FileSystem::)update_command_output() -> (FileSystem::)update_command_progress() errorcapture.signal_update -> (FileSystem::)update_command_output() update_command_progress() signal_progress.emit(...) FileSystem::signal_progress --------------------------- connected in ext2::resize() signal_progress -> ext2::resize_progress() connected in ext2::create() signal_progress -> ext2::create_progress() ... Thanks, Mike
For comparison without any renaming the signals and callbacks would be called: PipeCapture::update ------------------- connected in FileSystem::execute_command() outputcapture.update -> (FileSystem::)relay_update() -> (FileSystem::)relay_outputupdate() errorcapture.update -> (FileSystem::)relay_update() relay_outputupdate() outputupdated(...) FileSystem::outputupdated ------------------------- connected in ext2::resize() outputupdated -> ext2::resize_update() connected in ext2::create() outputupdated -> ext2::mkfs_update()
Hi Mike, I have successfully tested the patch in comment #13. If there are no changes and I do not hear any objections in the next few days, then I will commit this patch. After that we can proceed with the review and any updates needed for the patches in comments 8, 9, and 10.
Hi Mike and Phillip, The class and method renames in the patch from comment #13 have been committed to the git repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Rename class utils_execute_command_status https://git.gnome.org/browse/gparted/commit/?id=30946cb812e2c745968773c756d715713824c8e2 Rename signals update and eof https://git.gnome.org/browse/gparted/commit/?id=0d52cd19d7ead3aaca39caf79ecaec87866f5224 Rename function relay_update https://git.gnome.org/browse/gparted/commit/?id=d6260e17b377a0146fc690f7689c48f80dc8b9aa Mike, since you initiated the class and method renames, perhaps you could make any necessary updates to Phillips patches in comments 8, 9, and 10?
Created attachment 243846 [details] [review] Progress bars (v2) Hi Phillip and Curtis, Here's Phillip's patch set updated with the discussed renaming. Also added c.disconnect() missing from ext2::check_repair(). I'll review this over the next day or two. Phillip, One initial question. On which OS and with which version of e2fsprogs did you get ascii 0x01 and 0x02 characters being outputted by e2fsck? I've not seen them myself on an initial check. Thanks, Mike
e2fsck deliberately brackets the progress bar with control-A (ASCII 001, Start of Header) and control-B (ASCII 002, Start of Text) when it detects that it is not being run from a terminal so that logsave(8) can exclude the progress bar from being written to a log file. As GParted doesn't run e2fsck via a pty it receives these control characters. Refs: Change e2fsck to bracket its progress bar output with ctrl-A and ctrl-B http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=bc34d6be65cb93a65451ad209cfea2f98b03fd22 Don't print ^A and ^B chars when e2fsck is talking directly to a tty http://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=54a31a3b2e432c124aa03442f2983c4f4d4a974c Debian Bug #204137 - fsck.ext2: "-C 0" prints junk on an xterm http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204137
The patch in comment #17 looks good to me. Using the patch I have successfully tested resizing ntfs and ext4, and checking ext4 on the following distros: kubuntu 12.04 openSUSE 11.2 Fedora 16 Debian 6 Mike, Would you be able to test on a supported version of Red Hat or CentOS?
Initial code review comments: (Cosmetic in nature) 1) In PipeCapture::OnReadable() change integer constants 1 & 2 to char constants '\x01' and '\x02' and add code comment: //Skip Ctrl-A and Ctrl-B chars e2fsck uses to bracket the progress bar Add a shortened version of comment #18 to the commit message. -- This avoids mental discontinuity between OnReadable() checking for characters at one moment and integers at another. It also explains why it's going on. 2) In ext2::check_repair_progress() and ntfs::resize_progress() rename local variable fact to pct/pctage/percentage. Another mental discontinuity between a variable called faction but storing a percentage. Moving on to realistic testing now ... Mike
CentOS 5.9: * Confirmed all commits compile. * Passed testing. After my testing I have a question. Do we want to give users these progress bars? Normally a progress bar goes from 0 to 100% percent possibly with varying speed, but these progress bars aren't that simple to the users. Take the single GParted operation of shrinking an ext2/3/4 file system as an example. The user will see the progress bar pulsing back and forth, interspersed most of the time with at least 4 periods of it growing from 0 to 100%. Will the users understand this behaviour? Will they appreciate this behaviour and thank us or complain and want a simple progress bar? For example why is this style of progress bar better than the pulse bar, when both probably required the user to look at the details to understand what is happening? I just want us to make a positive choice that this is good and know how to explain it to our users before we commit it. Thanks, Mike
Hi Mike, In the GNOME Human Interface Guidelines, one of the usability principles is to "keep the user informed". I believe progress bars fall under this guideline. The previous progress bar for these tasks would simply bounce back and forth. This at least let the user know that the application had not froze, but provided little else. With the code refactoring, we added more progress feedback by tracking and displaying the live output from the command details. This certainly helps to keep users informed, but does require the user to expand the details to see what is occurring. > Do we want to give users these progress bars? I think this progress bar is an improvement, though I do agree that it is not as simple to understand as a single bar that progresses _once_ from left to right. > Will the users understand this behaviour? I believe many will understand the behaviour because GParted lists the running task near the progress bar (e.g., "check file system on ..."). > Will they appreciate this behaviour and thank us or complain and want > a simple progress bar? I believe the ultimate goal is to have a single progress bar. However, I do not know how we can provide this level of simplicity. I think that everything we've done so far helps improve feedback so is in the correct direction. > For example why is this style of progress bar better than the pulse > bar, when both probably required the user to look at the details to > understand what is happening? With these new progress bars for ntfs and ext2/3/4 resizing and ext2/3/4 file system checking, the user will see the progress bar build across the screen without needing to expand the details. For small file systems there is almost no difference from the previous bouncing bar. With large file systems that take a long time to process, then I think the progress bar will be preferred. An example of multiple displays of the bar progressing from left to right occurs when we copy or move a file system. Each stage of trying a different block size (1 MiB up to 16 MiB) grows a complete progress bar. We have not had complaints about this to date. I think that most users will see this as an improvement. Mike, is there an issue with these progress bars that you have come across in your testing?
One quote that I can find from the GNOME HIG that might suggest we should stay with the bounce left and right progress bar is as follows: https://developer.gnome.org/hig-book/stable/principles-feedback.html.en It is critical that feedback be accurate and precise. If you display a determinate progress indicator to display the state of completion of a task and it is inaccurate, the user will lose faith in progress indicators, and they will find the environment less usable. To make the progress bar more accurate, we would need to know how many subtasks the operation would take, and then divide the bar into sectors for each of the tasks. For example, when growing a partition, the following steps are used: 1. Calibrate fast 2. Check file system slow 3. Grow partition fast 4. check file system slow (this step looks redundant) 5. grow file system slow We could consider a single progress bar that consists of 5 parts for these 5 steps. However, the growth of the bar would vary greatly from step to step. Hmmm.... what to do? Phillip, any thoughts?
(In reply to comment #23) > For example, when growing a partition, the following steps are used: > > 1. Calibrate fast > 2. Check file system slow > 3. Grow partition fast > 4. check file system slow (this step looks redundant) > 5. grow file system slow > > We could consider a single progress bar that consists of 5 parts for these 5 > steps. However, the growth of the bar would vary greatly from step to step. Not that I'm Phillip, but in this case the single progress bar should be divided into three; one part for each slow step. During the fast steps the progress bar can just as well stand still. Assuming the steps are actually fast, the progress bar won't pause for long anyway, and the user will better see the progress of the slow steps. Just my €0.02.
Oh boy, for some reason I wasn't on the Cc list so I've got some catching up to do. Let's see... The first renames look fine. My brain just knows a character is an integer, just a small one, and has no trouble flipping back and forth, but I suppose you can change that if you like. I'm not sure what you mean about the percentage vs fraction... they are the same thing? On the progress bars, the problem with trying to divide it to account for the sub operations is that we can't tell how long each sub operation will take. For instance, fsck on ext2/3 takes a while, but is almost instant on ext4, so if we divide the check/grow/check into 3 equal parts, we'd spend almost all of our time in the 33-66% range, and blast through the first and last third. I think we just should identify the worst instances of this problem, and see if we can promote the slower sub operations to top level operations so they will each get their own bar all to themselves. I think that should work for the check/grow/check. As long as the vast majority of the time we spend showing one slow operation, with a few very fast ones, it's a little sub optimal, but not too bad. Certainly much better than not showing any progress at all.
Hi Phillip, Initially can you submit your patch set with just the changes required to turn on the progress bars from the e2fs and ntfs commands and have them appear in the text details. Leave updating of the GParted progress bar out. This is a useful first step we can easily commit upstream. Afterwards we can work on a method for updating the GParted progress bar and optionally talk to the GNOME Design Team https://live.gnome.org/Design/ for suggestions or a review. Thanks, Mike
I don't understand. You mean show "50% done" as text, but not visually? That doesn't make sense to me. Are there any other problem spots besides the check/resize/check, and the block size calculation?
Just add the flags to the resize2fs, ntfsresize, mkfs.ext* and e2fsck commands with the required change to OnReadable() to skip Ctrl-A and Ctrl-B chars. (This gives useful output visible when by expanding the details).
Oh. I'd really rather update the progress bars since that was the whole point of this. I think I'll take a crack at getting rid of the block size tests and moving the pre/post fscks on resize to their own top level operation and see if that takes care of everything.
Hi Phillip, I think Mike's intention in comment #28 is that we could commit the flag changes immediately because these would help with the details pane. The concern with the whole progress bar improvement is to get better alignment with the GNOME HIG which requires some more thought and work. If you prefer, we could place the flag changes in: Bug #697662 - Do not hide the progress of the tools used since I believe that this is what 697662 was to address. Curtis
I don't think there's a rush to get another release out in the next day or two is there? The fixes shouldn't take long so I don't see a reason to rush a half solution.
Presently there is no rush. We try to target a new release every two months or so. If we discover anything that can cause a loss of data then we will work to get out a release much sooner, like we did with 0.16.1.
The more I look at this, the more I think it's fine the way it is. Having the bar *sometimes* restart is much better at "keeping the user informed" than uselessly ping ponging back and forth all the time. Getting it perfect would be nice, but looks like it will take a lot more work than it's worth. I still think the unneeded block size calibration in the copy operation should be removed, and maybe the automatic fscks as well?
Hi Phillip, Regarding the code enhancements in the patch, I am 100% on board with the flag changes to permit the commands to output progress which is tracked in the details. The area where it gets grey is not the progress bar bar itself, but the multiple progress bars that occur with a single operating. This appears to be in contradiction with the GNOME HIG as quited in comment #23. Having said that, GParted already contains another contradiction to the GNOME HIG with the progress bars while the optimal block size is determined. Since we have not had users complaining about the optimal block size determination, I would be okay with committing this patch and then see how it is accepted. We can always roll back the change in a subsequent release. Mike, What do you think? Do you feel strongly one way or the other on this topic? Phillip and Mike, > I still think the unneeded block size calibration in the copy operation > should be removed, and maybe the automatic fscks as well? I agree that the block size calibration adds less value now that recent drives contain caches, often larger than the 16 MiB maximum block size used by GParted. Regarding the automatic fscks, I believe these add value and help to ensure the integrity of data. For example, when resizing, GParted will ensure that a file system check passes before trying to run the resize command. If the file system check failed, then I think it is unwise to try to continue to resize the file system.
Phillip, To enable ease of potential rollback, it would help to have the flag changes to the commands in a separate commit.
Phillip, Yes please to separate commits. Makes rolling back individual changes much easier. Curtis, For me the problem case is resize2fs which has 3 or 4 progress bars for a single command. I'll go with your decision though. (The other commands with a few seconds of pulsing before and after a single progress bar taking most of the time are OKish). The internal copy calibration falls into the OKish category in my view. All 5 tests take < ~6 seconds and the progress bars flash past very quickly so don't really register as such.
Often thinking on a problem for while can produce a better solution. As such I would be in favour of committing only the command flag changes now. We would then hold off on the progress bar changes while we let our subconscious mull over other possible solutions.
*** Bug 709276 has been marked as a duplicate of this bug. ***
Created attachment 258499 [details] [review] 0001-Display-progress-during-resize-467925.patch
Created attachment 258500 [details] [review] 0002-Display-progress-for-mke2fs-467925.patch
Created attachment 258501 [details] [review] 0003-Display-progress-for-e2fsck-467925.patch
I have rebased the patches onto current master.
Hi Phillip, I have to admit that I have not tested the new patches starting with comment #39. Has the behaviour of the status bars changed from the earlier patches? Back before you improved the internal GParted move operation, I used to receive complaints about the full read of the partition before the full move of the partition. Users would say that they thought the operation was almost done, but it would only have completed reading the sectors and would proceed to take at least as long to move the partition to the new location. If possible I would like to avoid these types of complaints. Curtis
No, the behaviour has not changed. Time to think on it has not changed my opinion: we can't get the bar perfect, but spending an hour slowly filling up and then spending 1 minute racing through another full bar is a lot better than spending 61 minutes bouncing back and forth. We got rid of the read-only pass already didn't we?
(In reply to comment #44) > No, the behaviour has not changed. Time to think on it has not changed my > opinion: we can't get the bar perfect, but spending an hour slowly filling up > and then spending 1 minute racing through another full bar is a lot better than > spending 61 minutes bouncing back and forth. I agree. If there is only one long running action (and however many fast running actions) in an operation then the long running progress bar is representative of the time the operation takes to complete. The challenge is that some operations a user queues are actually compound actions. Further, more than one of these actions might take a long time. If there is more than one action taking a long time then the progress bars can be misleading to the user. For example, if a user chooses Partition -> Move/Resize, shrinks a partition and moves it to the left, a single GParted operation is queued. This operation actually involves several steps. 1) calibrate partition (fast) 2) check file system for errors (potentially slow) 3) shrink file system (potentially slow) 4) shrink partition (fast) 5) check file system for errors (probably faster check) 6) grow partition to be all-encompassing (fast) 7) move file system left (slow) 8) shrink partition (fast) As can be seen, there is more than one potentially long running step, because each of the check file system, shrink file system, and move file system actions can take a long time. This is the problem that I see conflicting with the GNOME HIG. The root of the problem is that GParted only shows the user the queued operation, and then each successive sub-action as they occur. If instead these sub-actions were all displayed earlier, or somehow the total number of sub-actions were shown and progress through these, then we could eliminate the progress bar confusion for the user. My thoughts are that tracking the number of sub-actions might be one way to address this confusion. The reason being that when the operation is queued, we will know at that time how many sub-actions are required. Of course we will also need to take into account merging operations when the user keeps changing the same partition. > We got rid of the read-only pass already didn't we? Yes, the read-only pass is now gone. :) Before that enhanecment there were two long progress bars (and some bounce-back bars). One long progress bar to do the read-only pass, and a second to perform the actual move/copy of the data. This is the area where I received complaints from users that thought the operation was done after the read-only pass because the bar had progressed all the way across. Then all of a sudden it started from scratch again for the move/copy of the file system. This led to confusion as to when the task was really going to be done. Curtis
Oh right... the second progress bar does not count the sub operations. I suppose that is something that could be improved on, but would require some significant refactoring so I'm not sure why the initial improvement needs to wait on that. Keep in mind that for every one person that complains that they thought it was almost done and then the bar started over, there are 10 people complaining that it has been running for hours and the stupid bar just keeps bouncing back and forth giving no indication at all, is it stuck? Should I kill it?
You raise a good point Phillip that some people will prefer the progress bar as it works in the patch set and other people will prefer it as is. This and the HIG are what make the patch set fall into a grey area. This issue is first raised by Mike in comment #21. Since this issue is not a simple case of one way being right and another being wrong, and because I do not want to lose the work done in this patch set, I am leaning towards including it in a release after 0.17.0. One main reason I prefer to skip this for the 0.17.0 release is because the patches include tie-ins to signal handlers and as such should undergo extensive testing. I want to be sure this is well tested on supported distros before committing this to the master branch.
I will inject a reminder here of my original post (following paragraph). I used gparted only once, in an emergency. I may use it again if such an emergency comes up, although it did not find my partitions, took a long long time trying, and then threw away all the results when the drive got disconnected after 12 hours due to a USB fluke, rather than detecting that and letting me perhaps reconnect and continue. (The free version of DMDE worked, found three large FAT32 partitions within a fraction of a second, and let me recover them perfectly.) "I'm doing a search-for-file-systems operation on a 2tb drive. It has been running for almost 12 hours. Having never done this before I really have no idea whether it might take the rest of the week, also whether it is likely to survive sleep/wake cycles for several days in a row." My real point is that gparted, being what it is, is likely to be used by people who have never used gparted before, and even: have never used unix before. And many people who are in an emergency situation are likely to be using it, although the converse may not be true. Finally: I have a kind of a schtick about participating in communities and giving feedback, and so I did in spite of the fact that it required finding out what bugzilla was and setting up an account. Many people in an emergency situation do not have spare cycles to give feedback. If it sucks, you will not hear from them. After all if it sucks it may not seem worth bothering to communicate, especially if there are weird hurdles involved (joining bugzilla). Progress bars are one of the primary things that make Windoze look like total crap, and the Mac (in most situations) look, well maybe not great, but certainly not disgusting, not utterly brain-dead and irritating. So these things make a difference in platform perception and adoption, never mind utilities. So I think it is good you keep plugging along and working on getting this right. Thanks! I can not remember the details of your progress bars after all this time, but what people sometimes miss in trying to get things right is additional modest things that might help an utterly disoriented user makes some sense of it all. As such, if there is some progress bar behavior that might be misleading, and especially if you have any cues from the operation queue that having such a misleading presentation is likely to come up in the current operation context, it would be helpful if you can in some way just warn the user with a textual status field to that effect, e.g. "such and such progress bar appear to indicate such and such but in fact [whatever, like maybe ...] there are other operations queued that are not being considered in the progress operation [or whatever else]. And finally you might even have some graphical red flag next to the progress bar when there is some information available to you to tell you it may not be a good indicator in the current situation. Or anything else: number of operations ahead still not considered in progress bar, etc. Bottom line: what can you do that is almost a UI-only thing with no underlying refactoring required, which even if it looks embarrassing, might be vastly helpful to an utterly disoriented user having a godawful emergency on their hands. Thanks.
As a heads up, I plan to begin reviewing the code for the patches contained in comment #39, comment #40, and comment #41. On another note, I am happy to announce that LarryT (previous GParted live CD maintainer and creator of some of the first GParted documentation) has offered to help out with testing these patches on various GNU/Linux distros. As such I have added his email address to the CC list on this report. Welcoming back to the team Larry. :) Curtis
Hi Phillip and Mike, I'm still backlogged in email so it's taking me a while to look through these patches. I noticed that the patch in comment #39 contains whitespace: $ git am bug467925-progress-bar-1.patch Applying: Display progress during resize (#467925) /home/gedakc/workspace/gparted.dev2/.git/rebase-apply/patch:113: trailing whitespace. partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) -1 ) + "K" ; warning: 1 line adds whitespace errors. This is one thing that we will want to clean-up before the final patch is approved. I still need to look at the method names too because some of these seem different from the patch in comment #17. Curtis
Hi all, I lately made some test with gparted compilled with those three patches Phillip submitted. And it seems that they introduce a new bug, when an ext2/3/4 ntfs grow operation is cancelled Current Gparted 0.17.0 behavior without patches: 1. grow partition 2. apply operation 3. cancel when file system is being resized 4. cancel button changes to « force cancel » so force cancel 5. operation cancelled 6. Operation reported as cancelled New Gparted 0.17.0 + 3 patches behavior: 1. grow partition 2. apply operation 3. cancel while file system is being resized 4. cancel button changes to « force cancel » so force cancel 5. operation still running, not cancelling 6. Operation reported as succesfully completed
Created attachment 266173 [details] details file when cancelling grow operation (0.17 + 3patches) in addition to my last comment https://bugzilla.gnome.org/show_bug.cgi?id=467925#c51
That is very strange; they shouldn't have a thing to do with the cancel path. I'll try to take a look at it tonight.
Hi Phillip, While working with Larry to get up to speed on testing, Larry and I have been conversing on the GParted IRC. Larry has performed many tests with these three patches on several distros. So far no crashes have been experienced. This is good news because with the troubles we encountered implementing asynchronous progress updates I was worried about crashes. Regarding cancel behaviour I have confirmed Larry's observation that with the 3 patches applied, cancelling a grow ext2 operation leaves the operation still running and then it gets reported as successfully completed. I performed my test on kubuntu 12.04. Curtis
Are you sure these patches introduce that behaviour or was it already there?
Hi Phillip, Like I mention in my previous post (comment 51), I made tests with both gparted version, current and patched. BTW Curtis got the same result when testing. So i can say this behaviour does not exist without the patches. But I must admit this is weird. Please, give it a try your self. Larry
Created attachment 266232 [details] cancelled operation, but successfully run Screenshot in addition to my previous comment 51 Larry
Phillip, Curtis, As I continued to have doubts about this bug I mentioned in comment 51(absolutly no effect when clicking the cancel button), I did several tests with the current gparted version compilled without any patch, and also with gparted-patched version compilled, on the same machine, changing directory. -1- the bug I previously mentioned may happen EVEN with the current version, depending on the moment one clicks the cancel button. If shrinking or growing is already too much committed, then clicking the cancel button does not make anything. FS = ext2/3/4 ntfs -2- cancelling with the gparted-patched version NEVER perform any cancelling operation, at any time. Either checking for error or growing or shrinking, it does nothing and operation continue just like no cancel order has been sent. So, IMHO, this could mean that the 3 patches highlight and increase a previous bug in the current version. Would there be other tests to confirm or deny all this ? Larry
I found this difficult to reproduce since resizse often finishes too quickly. Do you have a good way to make sure it takes a while? I wonder, is gparted trying to kill resize2fs, and it is just ignoring the signal for some reason?
(In reply to comment #59) > I found this difficult to reproduce since resizse often finishes too quickly. > Do you have a good way to make sure it takes a while? yes : I may use external usb drive. BTW it is 1 tera hdd, so it may take a while. > I wonder, is gparted > trying to kill resize2fs, and it is just ignoring the signal for some reason? So you wish I kill resizing ? Right ?
Hi Phillip and Larry, When I reproduced the cancel problem Larry discovered, I created an extended partition that spanned my whole 160 GB IDE drive. Then I created a 20 GB ext2 logical partition at the start of the drive and applied the operation. From there I grew the 20 GB ext2 partition to use the whole drive. When applying the grow operation I had sufficient time to watch the results and cancel the operation while it was in the resize2fs step. Curtis
You might try manually running resize2fs and hitting ctrl-c and make sure it stops, or insert a printf in FileSystem.cc:cancel_command() to make sure that it is sending the signal.
Created attachment 266280 [details] 0.17.0 grow ext2 operation cancel-force-cancel-cancel-operation at end of grow XXX line Hi Phillip and Larry, I manually ran the resize2fs command and it cancels when I press CTRL+C. Following is the output. Note that the terminal prompt gets written in the same line as the progress indicator because the final line feed is not sent. gedakc@octo:~/tmp$ sudo resize2fs -p /dev/sdd5 resize2fs 1.42 (29-Nov-2011) Resizing the filesystem on /dev/sdd5 to 39072000 (4k) blocks. Begin pass 1 (max = 1033) Extending the inode table XXXX^Cgedakc@octo:~/tmp$ --------------- I have been trying to replicate the situation Larry mentioned in comment #58 where he was able to get the current 0.17.0 version (no patches) to fail to cancel properly. So far I have been unsuccessful in duplicating this finding. Every time I cancel a grow ext2 operation in 0.17.0 the operation cancels as expected. The steps that occur in the grow operation are as follows: Grow /dev/sdd5 from 20.00 GiB to 149.05 GiB 1) calibrate /dev/sdd5 2) check file system on /dev/sdd5 for errors and (if possible) fix them 3) grow partition from 20.00 GiB to 149.05 GiB 4) check file system on /dev/sdd5 for errors and (if possible) fix them 5) grow file system to fill the partition Steps 1 and 3 run too fast for me to cancel. Steps 2 and 4 cancel immediately when I press cancel. Step 5 will display a "Force Cancel" button when I press cancel. Then if I press "Force Cancel" and also choose "Cancel Operation", the operation cancels. This even happens when I wait for all the resize2fs XXX's to progress all the way across the screen as demonstrated in the attached gparted_details.htm log file. My conclusion so far: A) 0.17.0 always cancels properly. B) git head + 3 patches, cancels in any operation never work. Another change I noticed is that with git head + 3 patches, if I cancel in steps 2 or 4 then I get a "Force Cancel" button that does not appear in 0.17.0. Curtis
Created attachment 266284 [details] cancelled operation, but successfully run After many test, I found one way to get the bug when cancelling with current version. But it is very difficult to reproduce. If cancelling during check file system after growing (or shrinking). And even I had to cancel twice : the first time it really cancels and the second time I run a check operation taht I cancel ! AFAIK, it is the only way to get this error. I add gparted_details too
Created attachment 266285 [details] gparted_details : cancelled operation, but successfully run add to my previous comment 64
Hi All, On a different issue, it looks like patch number 1/3 from comment #39 was miss-rebased because it is changing the following line in ext2::resize() which will re-introduce fault fixed by bug #701075, where ext[234] file systems were being resize 1 KiB too small. - partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) ) + "K" ; + partition_new .get_sector_length(), partition_new .sector_size, UNIT_KIB ) ) -1 ) + "K" ; Thanks, Mike
For a really simple way to test the bug, temporarly rename resize2fs out of the way and create a replacement script which just sleeps for 30 seconds. Like this: cd /sbin mv resize2fs resize2fs.save echo sleep 30 > resize2fs chmod a+x resize2fs
I haven't understood all the signals and callbacks involved, but removing the second call to outputcapture.signal_update.connect() added by patch number 1/3 from comment #39 allows resize to be cancelled again. But it's probably also going to stop the GUI progress bar being updated. --- a/src/FileSystem.cc +++ b/src/FileSystem.cc @@ -122,17 +126,14 @@ int FileSystem::execute_command( const Glib::ustring & command, OperationDetail std::vector<OperationDetail> &children = operationdetail.get_last_child().get_childs(); outputcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ), &(children[children.size() - 2]), &output ) ); errorcapture.signal_update.connect( sigc::bind( sigc::ptr_fun( update_command_output ), &(children[children.size() - 1]), &error ) ); - outputcapture.signal_update.connect( sigc::bind( - sigc::mem_fun( *this, &FileSystem::relay_outputupdate ), - operationdetail ) ); outputcapture.connect_signal(); errorcapture.connect_signal(); operationdetail.get_last_child().signal_cancel.connect( sigc::bind( sigc::ptr_fun( cancel_command ), pid, cancel_safe ));
Hi Larry, In comments #64 and #65 it looks like you cancelled when the resize2fs action was virtually complete. Did you get a chance to press the "Force Cancel" and then "Cancel Operation" buttons before the entire operation completed? My thoughts are that the 5 second delay before the "Force Cancel" button is activated might have been enough time for the grow operation to complete. If this is the situation then it is indeed a fringe case that not many would encounter. The one plus is that no data would be lost. Mike, Good catch on the re-introduction of an off-by-one problem in comment #66. Also I like your suggestion in comment #67 for how to test resize2fs by substituting a sleep script for this resize executable. Hopefully Phillip can now reproduce the problem and investigate further. Curtis
Good catch Mike, my eyes must have just glossed right over that -1. That is really fubar. All that call does is set it up so that the PipeCapture::OnReadable() callback is run whenever there is input to read from the pipe coming from the child. That callback reads from the pipe into a ustring, then emits the signal_update() signal, which changes the description in the OperationDetail to reflect the new progress. None of that should have anything to do with the cancel signal...
It looks like the problem is that the OperationDetails are copied around by the vector they are in, and the dtor in the original disconnects the signal. Removing the disconnect call in the OperationDetails dtor seems to fix it for me, how about you guys? I do not understand what that has to do with these patches though; it should have been a problem before.
(In reply to comment #71) > It looks like the problem is that the OperationDetails are copied around by the > vector they are in, and the dtor in the original disconnects the signal. > Removing the disconnect call in the OperationDetails dtor seems to fix it for > me, how about you guys? I do not understand what that has to do with these > patches though; it should have been a problem before. Hi Phillip. If you have time to set and post a patch I may test it... Larry
You just delete the only line that is in OperationDetail::~OperationDetail ;)
(In reply to comment #73) > You just delete the only line that is in OperationDetail::~OperationDetail ;) In which file ?
Hi Larry, This is the change Phillip is alluding to in file src/OperationDetail.cc: diff --git a/src/OperationDetail.cc b/src/OperationDetail.cc index 86b4127..af460a0 100644 --- a/src/OperationDetail.cc +++ b/src/OperationDetail.cc @@ -36,7 +36,6 @@ OperationDetail::OperationDetail( const Glib::ustring & description, OperationDe OperationDetail::~OperationDetail() { - cancelconnection.disconnect(); } void OperationDetail::set_description( const Glib::ustring & description, Font font ) Thanks, Mike
When I tested this change it didn't go so well. GParted core dumped as soon as the cancel button was pressed for the first time. This was when cancelling "sleep 30" shell script named /sbin/resize2fs. [root@rockover ~]# gdb ~mike/programming/c/gparted/src/gpartedbin core.19179 (gdb) set pagination off (gdb) list 993 * @param last An iterator pointing to the last slot in the list. 994 * @param _A_a1 Argument to be passed on to the slots. 995 */ 996 static result_type emit(signal_impl* impl, typename type_trait<T_arg1>::take _A_a1) 997 { 998 if (!impl || impl->slots_.empty()) return; 999 signal_exec exec(impl); 1000 temp_slot_list slots(impl->slots_); 1001 1002 for (iterator_type it = slots.begin(); it != slots.end(); ++it) (gdb) backtrace
+ Trace 233051
Yikes.. I was just testing with a fsck instead of a resize. It looks like the problem is that sigc's connection object doesn't do ref counting so isn't suitable for use in objects that are ever copied. Curtis, I think you have more experience with the sigc library than I do; do you have any insight on how this might be dealt with, or somewhere to discuss it?
Hi Phillip, Mike, and Larry, In response to comment #77, I am certainly not an expert on the sigc library. What I do know is that this area seems to be really sensitive or touchy. I base this "touchy" feeling on the many crash problems we encountered while trying to add asynchronous command spawning and detail window updating. As a suggestion of "somewhere to discuss it", I have created a post in the GParted Forum under General Development. Feel free to add to the forum post thread at: Add Progress Bar Discussion http://gparted-forum.surf4.info/viewtopic.php?id=17079 Curtis
I meant is there an upstream mailing list for sigc or something?
Created attachment 266910 [details] [review] Progress bars (v4) In an effort to ensure that we do not lose the suggestions mentioned in comment #50 and comment #66, I have applied these suggestions and rebased the patch set. The updates in this patch set include: 1) Remove trailing white space (and clean up some prior white space nearby) 2) Remove reintroduction of "-1" size calculation problem for ntfs resize Note that this patch set includes all 3 of the previous patches listed as attachments in comments 39, 40, and 41. I still need to look more closely at how we are handling signals and asynchronous spawned commands with respect to problems with this patch set. Curtis
Created attachment 267084 [details] [review] Progress bars (v5) Hi, Here's v5 of the patchset. The following differences have been made compared to v4 from comment #80: Re-apply changed made in v2 from comment #17 and discussed in comment #13 above: 1) Renamed the functions and signals; 2) Explicitly call signal_progress.emit() rather than just signal_progress(), letting operator() map to emit(); 3) Readd missing c.disconnect() in ext2::check_repair(). Extras: 4) Define private functions after the public functions to match what is done in every other source file; 5) Drop "Ignore ascii 1 and 2, which e2fsck uses for some reason" from the 3rd commit message after that bit was already done by commit: Enable %age complete display from e2fsck command (#697662) https://git.gnome.org/browse/gparted/commit/?id=59a22673da55eb185b8bd1e25cc9a729e24c24bb 6) Remove white space changes to existing non-white space lines in ext2::resize() which would pollute git blame. NOTE: This still doesn't address the inability to cancel an ext2/3/4 and ntfs resize first noted in comment #51. Mike
Created attachment 270295 [details] [review] 0001-Fix-cancel-path.patch Ok, so the disconnect is needed because the old OperationDetail goes away, so the parent OperationDetail needs to no longer be connected to it. The NEW OperationDetail needs to establish a new connection from the parent to itself. This patch should do it. Note that it still does not seem to be connected to the progress changes.
Hi guys, I gonna make some tests with those two patches, applying both to last gparted release commit from git. Please let me know if you have any wishes or details about needed tests, or I only run usual test ? thx Larry
When applying the patchv5, it returns an error : Applying: Display progress during resize (#467925) error: patch failed: src/ext2.cc:193 error: src/ext2.cc: patch does not apply Patch failed at 0001 Display progress during resize (#467925) The copy of the patch that failed is found in: /home/trog/gparted-467925/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". Please, let me know what I miss :/
Hi Larry, I discovered the same problem when I tried to apply the patch from comment #81 to the current git master. When this occurs, usually the git master branch has changed sufficiently that there is now a conflict or missing markers for the patch to be cleanly applied. This means that the patch needs to be rebased with the current git master branch. To restore the original branch and stop patching run "git am --abort". Mike, If you have time, would you be able to rebase the patches from comment #81 and comment #82? If not, then let me know and I can take a look into it. In the meantime I will review and possibly commit the latest patch for: Bug 721516 - Use e2image to move/copy ext[234] filesystems Thanks, Curtis
Hi All, I've some time so I will work on refactoring the patches in comment 81 and comment 82. Curtis
Created attachment 272880 [details] [review] Progress bars (v6) Hi All, Here's v6 of the patch set. It contains only the rebased v5 patch set. The changes that caused trouble were due to some move() formatting changes, and the migration of a calculation to an offset variable. NOTE: This v6 patch set still doesn't address the inability to cancel an ext2/3/4 and ntfs resize first noted in comment #51. PROBLEMS WITH 0001-Fix-cancel-path.patch FROM COMMENT #82 When I applied 0001-Fix-cancel-path.patch from comment #82 on top of the v6 patch set, I discovered that each operation I queued then applied would result in a GParted crash (most often a segmentation fault, though sometimes memory allocation problems). Some of the operations I tried were create ext2 or fat16 partition, resize ext2 or ntfs partition, check ext2 or ntfs partition, and label ntfs partition. I quickly tested some of these operations on Ubuntu GNOME 14.04 beta1 and experienced similar GParted crashes. Phillip, Was your intention to apply the 0001-Fix-cancel-path.patch from comment #82 on top of the progress-bar-v# patch sets? Do you encounter the same GParted crashes with the 0001-Fix-cancel-path.patch from comment #82? Curtis
Created attachment 272884 [details] [review] Progress bars (v7) Doh! My bad. Patch set v6 accidentally included 0001-Fix-cancel-path.patch from comment #82. The progress bars (v7) patch excludes 0001-Fix-cancel-path.patch from comment #82. NOTE: This v7 patch set still doesn't address the inability to cancel an ext2/3/4 and ntfs resize first noted in comment #51. Curtis
I forget whether I had it on top of or under, but it probably should be applied whether or not the progress bar is applied as the bug appears to be unconnected to it.
Hi Phillip, When I apply only the 0001-Fix-cancel-path.patch from comment #82 on top of the currently published git master branch (with no progress-bar-v# patches), then queue and apply an operation, there are no progress bar updates. In addition if I expand the details pane, then the command line specifics are blank, and the error/output is also blank. There are some unusual numbers for timing on the right hand side. when the command supposedly competes, GParted crashes. Would you be able to test the patch from comment #82 to see if it works for you? Curtis
Jesus... while debugging this I did the stupidest thing in the world, then fixed it because I'm a frigging genius ;) I meant to test on my flash drive in /dev/sde, but I accidentally created a partition table on /dev/md0 instead, which is my sole lvm pv that contains everything on my system. This of course wiped out my lvm pv. Fortunately I did not panic ( much ), and was able to wipe the mbr and recreate the lvm pv header and restore the lvm config from the backup in /etc/lvm/backup which, even though it was on the lvm, still worked as long as I didn't reboot. Whew... dodged a bullet there. This experience made me realize it would be really nice if gparted recognized an lvm pv on a whole disk instead of saying it was an unpartitioned disk. I realized that the patch still isn't right since the parent OperationDetail can be moved, thus invalidating the pointer the child has to it. I think the whole OperationDetail.cc needs to be re-factored to avoid using std::vector to hold its children. As a general rule, nothing more complex than a built in type or pointer should be stored in STL containers. In other words, instead of having a std::vector<OperationDetail> children, the class should have std::vector<OperationDetail *>children.
Hi Phillip, Thank you for testing the patch and confirming that more work is needed. I'm glad that you were able to recover your LVM PV on your RAID. I also test on my PC and am always worried that I might overwrite the OS accidentally. To avoid GParted seeing any of my OS or DATA disks as unformatted/unpartitioned, I always create a partition table, even if the table contains only one partition that spans the drive. Having said that, this is no guarantee of accidentally overwriting the OS or data. I agree that it would be nice if GParted recognized the format of non-partitioned devices. Along that line of thinking I'll take a look at the status of Bug 683643 - Doesn't properly support partitionless drives. Curtis
Created attachment 273443 [details] [review] 0001-Refactor-OperationDetail-to-not-store-complex-object.patch Ok, this should fix the underlying bug.
Hi All, The patch from comment #93 has been moved into it's own bug report to enable it to be tested and committed prior to this report being addressed. See: Bug 729139 - Refactor OperationDetail to address random behavior The bug report for 467925 will remain open to handle the issue mentioned in the title (gparted: add progress bar during operation). Larry, If you have a chance, please test the new patch posted in Bug 729139 and report your findings in that report. Curtis
Hey Curtis, it looks like this fell off the radar some time ago. Any chance you can apply it now?
Created attachment 316655 [details] [review] Progress bars (v8) Hi All, Here's v8 of the patchset. The only difference compared to v7 from comment #88 is forward port to current published git master and a couple of trivial white space changes. Current git master: 5b0465e Make about dialog website link non-clickable (#758131) Unfortunately as soon as operations start being applied GParted core dumps with heap corruption. Often/Always affects non-modified operations too. At the moment I'm not sure if this is uncovering an existing bug or whether this patchset is buggy. Mike # ~mike/programming/c/gparted/src/gpartedbin ====================== libparted : 2.4 ====================== *** glibc detected *** /home/mike/programming/c/gparted/src/gpartedbin: double free or corruption (!prev): 0x00000000025d13b0 *** # gdb ~mike/programming/c/gparted/src/gpartedbin core.15044 --batch --quiet --ex backtrace -ex quit [New Thread 15044] [New Thread 15046] [Thread debugging using libthread_db enabled] Core was generated by `/home/mike/programming/c/gparted/src/gpartedbin'. Program terminated with signal 6, Aborted.
+ Trace 235780
Thanks Phillip for the reminder to look at this again. Also thank you Mike for rebasing the patch set. I applied patch set v8 from comment #96 and tested on kubuntu 12.04. I encountered a similar problem to Mike. I queued an operation to create a 2,048 MiB NTFS partition and then applied the operation. GParted immediately crashed at the apply step with the error messages listed below. It looks like there is still more work to do before this enhancement is ready to be committed to the git master. Curtis Error messages follow: $ sudo ./gparted.test.sh /dev/sde [sudo] password for gedakc: ====================== libparted : 2.3 ====================== *** glibc detected *** src/gpartedbin: free(): invalid pointer: 0x00000000026a5018 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x7db26)[0x7f0ce567eb26] /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib7ustringD1Ev+0x39)[0x7f0ce72b89b9] src/gpartedbin[0x4a1a91] src/gpartedbin[0x46d15b] src/gpartedbin[0x4e7873] src/gpartedbin[0x47ee9b] src/gpartedbin[0x48adf6] src/gpartedbin[0x455cea] /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f0ce72b6e08] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x20fdd)[0x7f0ce6b86fdd] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd79)[0x7f0ce6b8f069] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_widget_show+0x86)[0x7f0ce772ccb6] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_dialog_run+0x218)[0x7f0ce758fdb8] src/gpartedbin[0x4c03fa] /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1(_ZN4Glib17SignalProxyNormal19slot0_void_callbackEP8_GObjectPv+0x28)[0x7f0ce72b6e08] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x20fdd)[0x7f0ce6b86fdd] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xd79)[0x7f0ce6b8f069] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x504)[0x7f0ce6b8f724] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0xfeca)[0x7f0ce6b75eca] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x421)[0x7f0ce6b8e711] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8e8e5)[0x7f0ce75628e5] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0xfeca)[0x7f0ce6b75eca] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x421)[0x7f0ce6b8e711] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8d70d)[0x7f0ce756170d] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x136e78)[0x7f0ce760ae78] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x132)[0x7f0ce6b75ca2] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21339)[0x7f0ce6b87339] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xa5e)[0x7f0ce6b8ed4e] /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x82)[0x7f0ce6b8f212] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x251231)[0x7f0ce7725231] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc3)[0x7f0ce7609003] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x283)[0x7f0ce7609363] /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5be5c)[0x7f0ce6e10e5c] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x133)[0x7f0ce68b8d13] /lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x48060)[0x7f0ce68b9060] /lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f0ce68b945a] /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f0ce7608397] /usr/lib/x86_64-linux-gnu/libgtkmm-2.4.so.1(_ZN3Gtk4Main3runERNS_6WindowE+0x106)[0x7f0ce8491326] src/gpartedbin[0x41b442] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f0ce562276d] src/gpartedbin[0x41ba65] ======= Memory map: ======== 00400000-0053c000 r-xp 00000000 08:03 2621459 /home/gedakc/workspace/gparted/src/gpartedbin 0073b000-0073c000 r--p 0013b000 08:03 2621459 /home/gedakc/workspace/gparted/src/gpartedbin 0073c000-0073e000 rw-p 0013c000 08:03 2621459 /home/gedakc/workspace/gparted/src/gpartedbin 0073e000-00740000 rw-p 00000000 00:00 0 0229d000-02747000 rw-p 00000000 00:00 0 [heap] 7f0cc8000000-7f0cc8089000 rw-p 00000000 00:00 0 7f0cc8089000-7f0ccc000000 ---p 00000000 00:00 0 7f0cce9b9000-7f0cce9ba000 rw-p 00000000 00:00 0 7f0cce9ba000-7f0ccea19000 r--p 00000000 08:03 133796 /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-RI.ttf 7f0ccea19000-7f0ccea6b000 r--p 00000000 08:03 133790 /usr/share/fonts/truetype/ubuntu-font-family/Ubuntu-B.ttf 7f0ccea6b000-7f0ccea88000 r--p 00000000 08:03 533277 /usr/share/fonts/truetype/droid/DroidSansMono.ttf 7f0ccea88000-7f0cceae8000 rw-s 00000000 00:04 2785323 /SYSV00000000 (deleted) 7f0cceae8000-7f0cceae9000 ---p 00000000 00:00 0 7f0cceae9000-7f0ccf2e9000 rw-p 00000000 00:00 0 7f0ccf2e9000-7f0ccfb2d000 r--p 00000000 08:03 1200 /usr/share/icons/gnome/icon-theme.cache 7f0ccfb2d000-7f0cd0000000 r--p 00000000 08:03 5113632 /usr/local/share/icons/hicolor/icon-theme.cache 7f0cd0000000-7f0cd0022000 rw-p 00000000 00:00 0 7f0cd0022000-7f0cd4000000 ---p 00000000 00:00 0 7f0cd4000000-7f0cd8000000 r--p 00000000 08:03 131575 /usr/share/icons/oxygen/icon-theme.cache 7f0cd8000000-7f0cd8021000 rw-p 00000000 00:00 0 7f0cd8021000-7f0cdc000000 ---p 00000000 00:00 0 7f0cdc10a000-7f0cdd959000 r--p 00000000 08:03 133929 /usr/share/icons/hicolor/icon-theme.cache 7f0cdd959000-7f0cdd95d000 r-xp 00000000 08:03 5051291 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so 7f0cdd95d000-7f0cddb5d000 ---p 00004000 08:03 5051291 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so 7f0cddb5d000-7f0cddb5e000 r--p 00004000 08:03 5051291 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so 7f0cddb5e000-7f0cddb5f000 rw-p 00005000 08:03 5051291 /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so 7f0cddb5f000-7f0cddb61000 r-xp 00000000 08:03 4981613 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7f0cddb61000-7f0cddd60000 ---p 00002000 08:03 4981613 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7f0cddd60000-7f0cddd61000 r--p 00001000 08:03 4981613 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7f0cddd61000-7f0cddd62000 rw-p 00002000 08:03 4981613 /usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so 7f0cddd62000-7f0cddd63000 ---p 00000000 00:00 0 7f0cddd63000-7f0cde563000 rw-p 00000000 00:00 0 7f0cde563000-7f0cde564000 ---p 00000000 00:00 0 7f0cde564000-7f0cded64000 rw-p 00000000 00:00 0 7f0cded64000-7f0cdeeb1000 r-xp 00000000 08:03 4981446 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so 7f0cdeeb1000-7f0cdf0b0000 ---p 0014d000 08:03 4981446 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so 7f0cdf0b0000-7f0cdf0b6000 r--p 0014c000 08:03 4981446 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so 7f0cdf0b6000-7f0cdf0b9000 rw-p 00152000 08:03 4981446 /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/engines/liboxygen-gtk.so 7f0cdf0b9000-7f0cdf0ba000 rw-p 00000000 00:00 0 7f0cdf0ba000-7f0cdf0c6000 r-xp 00000000 08:03 4720110 /lib/x86_64-linux-gnu/libnss_files-2.15.so 7f0cdf0c6000-7f0cdf2c5000 ---p 0000c000 08:03 4720110 /lib/x86_64-linux-gnu/libnss_files-2.15.so 7f0cdf2c5000-7f0cdf2c6000 r--p 0000b000 08:03 4720110 /lib/x86_64-linux-gnu/libnss_files-2.15.so 7f0cdf2c6000-7f0cdf2c7000 rw-p 0000c000 08:03 4720110 /lib/x86_64-linux-gnu/libnss_files-2.15.so 7f0cdf2c7000-7f0cdf2d1000 r-xp 00000000 08:03 4718878 /lib/x86_64-linux-gnu/libnss_nis-2.15.so 7f0cdf2d1000-7f0cdf4d1000 ---p 0000a000 08:03 4718878 /lib/x86_64-linux-gnu/libnss_nis-2.15.so 7f0cdf4d1000-7f0cdf4d2000 r--p 0000a000 08:03 4718878 /lib/x86_64-linux-gnu/libnss_nis-2.15.so 7f0cdf4d2000-7f0cdf4d3000 rw-p 0000b000 08:03 4718878 /lib/x86_64-linux-gnu/libnss_nis-2.15.so 7f0cdf4d3000-7f0cdf4ea000 r-xp 00000000 08:03 4724968 /lib/x86_64-linux-gnu/libnsl-2.15.so 7f0cdf4ea000-7f0cdf6e9000 ---p 00017000 08:03 4724968 /lib/x86_64-linux-gnu/libnsl-2.15.so 7f0cdf6e9000-7f0cdf6ea000 r--p 00016000 08:03 4724968 /lib/x86_64-linux-gnu/libnsl-2.15.so 7f0cdf6ea000-7f0cdf6eb000 rw-p 00017000 08:03 4724968 /lib/x86_64-linux-gnu/libnsl-2.15.so 7f0cdf6eb000-7f0cdf6ed000 rw-p 00000000 00:00 0 7f0cdf6ed000-7f0cdf6f5000 r-xp 00000000 08:03 4724969 /lib/x86_64-linux-gnu/libnss_compat-2.15.so 7f0cdf6f5000-7f0cdf8f4000 ---p 00008000 08:03 4724969 /lib/x86_64-linux-gnu/libnss_compat-2.15.so 7f0cdf8f4000-7f0cdf8f5000 r--p 00007000 08:03 4724969 /lib/x86_64-linux-gnu/libnss_compat-2.15.so 7f0cdf8f5000-7f0cdf8f6000 rw-p 00008000 08:03 4724969 /lib/x86_64-linux-gnu/libnss_compat-2.15.so 7f0cdf8f6000-7f0cdfd6c000 r--p 00000000 08:03 4593873 /usr/lib/locale/locale-archive 7f0cdfd6c000-7f0cdfd71000 r-xp 00000000 08:03 4595071 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0cdfd71000-7f0cdff70000 ---p 00005000 08:03 4595071 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0cdff70000-7f0cdff71000 r--p 00004000 08:03 4595071 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0cdff71000-7f0cdff72000 rw-p 00005000 08:03 4595071 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f0cdff72000-7f0cdff74000 r-xp 00000000 08:03 4595060 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0cdff74000-7f0ce0173000 ---p 00002000 08:03 4595060 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0ce0173000-7f0ce0174000 r--p 00001000 08:03 4595060 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0ce0174000-7f0ce0175000 rw-p 00002000 08:03 4595060 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f0ce0175000-7f0ce0181000 r-xp 00000000 08:03 4722301 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7f0ce0181000-7f0ce0380000 ---p 0000c000 08:03 4722301 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7f0ce0380000-7f0ce0381000 r--p 0000b000 08:03 4722301 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7f0ce0381000-7f0ce0382000 rw-p 0000c000 08:03 4722301 /lib/x86_64-linux-gnu/libudev.so.0.13.0 7f0ce0382000-7f0ce03a9000 r-xp 00000000 08:03 4720130 /lib/x86_64-linux-gnu/libexpat.so.1.5.2 7f0ce03a9000-7f0ce05a9000 ---p 00027000 08:03 4720130 /lib/x86_64-linux-gnu/libexpat.so.1.5.2 7f0ce05a9000-7f0ce05ab000 r--p 00027000 08:03 4720130 /lib/x86_64-linux-gnu/libexpat.so.1.5.2 7f0ce05ab000-7f0ce05ac000 rw-p 00029000 08:03 4720130 /lib/x86_64-linux-gnu/libexpat.so.1.5.2 7f0ce05ac000-7f0ce05c4000 r-xp 00000000 08:03 4724961 /lib/x86_64-linux-gnu/libresolv-2.15.so 7f0ce05c4000-7f0ce07c4000 ---p 00018000 08:03 4724961 /lib/x86_64-linux-gnu/libresolv-2.15.so 7f0ce07c4000-7f0ce07c5000 r--p 00018000 08:03 4724961 /lib/x86_64-linux-gnu/libresolv-2.15.so 7f0ce07c5000-7f0ce07c6000 rw-p 00019000 08:03 4724961 /lib/x86_64-linux-gnu/libresolv-2.15.so 7f0ce07c6000-7f0ce07c8000 rw-p 00000000 00:00 0 7f0ce07c8000-7f0ce07e5000 r-xp 00000000 08:03 4722384 /lib/x86_64-linux-gnu/libselinux.so.1 7f0ce07e5000-7f0ce09e4000 ---p 0001d000 08:03 4722384 /lib/x86_64-linux-gnu/libselinux.so.1 7f0ce09e4000-7f0ce09e5000 r--p 0001c000 08:03 4722384 /lib/x86_64-linux-gnu/libselinux.so.1 7f0ce09e5000-7f0ce09e6000 rw-p 0001d000 08:03 4722384 /lib/x86_64-linux-gnu/libselinux.so.1 7f0ce09e6000-7f0ce09e7000 rw-p 00000000 00:00 0 7f0ce09e7000-7f0ce09fd000 r-xp 00000000 08:03 4722407 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f0ce09fd000-7f0ce0bfc000 ---p 00016000 08:03 4722407 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f0ce0bfc000-7f0ce0bfd000 r--p 00015000 08:03 4722407 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f0ce0bfd000-7f0ce0bfe000 rw-p 00016000 08:03 4722407 /lib/x86_64-linux-gnu/libz.so.1.2.3.4 7f0ce0bfe000-7f0ce0c06000 r-xp 00000000 08:03 4595414 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 7f0ce0c06000-7f0ce0e06000 ---p 00008000 08:03 4595414 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 7f0ce0e06000-7f0ce0e07000 r--p 00008000 08:03 4595414 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 7f0ce0e07000-7f0ce0e08000 rw-p 00009000 08:03 4595414 /usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0 7f0ce0e08000-7f0ce0e0a000 r-xp 00000000 08:03 4595462 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 7f0ce0e0a000-7f0ce1009000 ---p 00002000 08:03 4595462 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 7f0ce1009000-7f0ce100a000 r--p 00001000 08:03 4595462 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 7f0ce100a000-7f0ce100b000 rw-p 00002000 08:03 4595462 /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0 7f0ce100b000-7f0ce1031000 r-xp 00000000 08:03 4726767 /lib/x86_64-linux-gnu/libpng12.so.0.46.0 7f0ce1031000-7f0ce1231000 ---p 00026000 08:03 4726767 /lib/x86_64-linux-gnu/libpng12.so.0.46.0 7f0ce1231000-7f0ce1232000 r--p 00026000 08:03 4726767 /lib/x86_64-linux-gnu/libpng12.so.0.46.0 7f0ce1232000-7f0ce1233000 rw-p 00027000 08:03 4726767 /lib/x86_64-linux-gnu/libpng12.so.0.46.0 7f0ce1233000-7f0ce12c3000 r-xp 00000000 08:03 4588682 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2 7f0ce12c3000-7f0ce14c2000 ---p 00090000 08:03 4588682 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2 7f0ce14c2000-7f0ce14c9000 r--p 0008f000 08:03 4588682 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2 7f0ce14c9000-7f0ce14ca000 rw-p 00096000 08:03 4588682 /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.30.2 7f0ce14ca000-7f0ce14e7000 r-xp 00000000 08:03 4590354 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0ce14e7000-7f0ce16e6000 ---p 0001d000 08:03 4590354 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0ce16e6000-7f0ce16e7000 r--p 0001c000 08:03 4590354 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0ce16e7000-7f0ce16e8000 rw-p 0001d000 08:03 4590354 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f0ce16e8000-7f0ce177f000 r-xp 00000000 08:03 4587930 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0 7f0ce177f000-7f0ce197e000 ---p 00097000 08:03 4587930 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0 7f0ce197e000-7f0ce1984000 r--p 00096000 08:03 4587930 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0 7f0ce1984000-7f0ce1985000 rw-p 0009c000 08:03 4587930 /usr/lib/x86_64-linux-gnu/libfreetype.so.6.8.0 7f0ce1985000-7f0ce19a7000 r-xp 00000000 08:03 4719145 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 7f0ce19a7000-7f0ce1ba7000 ---p 00022000 08:03 4719145 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 7f0ce1ba7000-7f0ce1baa000 r--p 00022000 08:03 4719145 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 7f0ce1baa000-7f0ce1bab000 rw-p 00025000 08:03 4719145 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 7f0ce1bab000-7f0ce1bcb000 r-xp 00000000 08:03 4719117 /lib/libdevmapper.so.1.02.1 7f0ce1bcb000-7f0ce1dcb000 ---p 00020000 08:03 4719117 /lib/libdevmapper.so.1.02.1 7f0ce1dcb000-7f0ce1dcc000 r--p 00020000 08:03 4719117 /lib/libdevmapper.so.1.02.1 7f0ce1dcc000-7f0ce1dce000 rw-p 00021000 08:03 4719117 /lib/libdevmapper.so.1.02.1 7f0ce1dce000-7f0ce1dd0000 r-xp 00000000 08:03 4724971 /lib/x86_64-linux-gnu/libdl-2.15.so 7f0ce1dd0000-7f0ce1fd0000 ---p 00002000 08:03 4724971 /lib/x86_64-linux-gnu/libdl-2.15.so 7f0ce1fd0000-7f0ce1fd1000 r--p 00002000 08:03 4724971 /lib/x86_64-linux-gnu/libdl-2.15.so 7f0ce1fd1000-7f0ce1fd2000 rw-p 00003000 08:03 4724971 /lib/x86_64-linux-gnu/libdl-2.15.so 7f0ce1fd2000-7f0ce1fd9000 r-xp 00000000 08:03 4720117 /lib/x86_64-linux-gnu/librt-2.15.so 7f0ce1fd9000-7f0ce21d8000 ---p 00007000 08:03 4720117 /lib/x86_64-linux-gnu/librt-2.15.so 7f0ce21d8000-7f0ce21d9000 r--p 00006000 08:03 4720117 /lib/x86_64-linux-gnu/librt-2.15.so 7f0ce21d9000-7f0ce21da000 rw-p 00007000 08:03 4720117 /lib/x86_64-linux-gnu/librt-2.15.so 7f0ce21da000-7f0ce2216000 r-xp 00000000 08:03 4726756 /lib/x86_64-linux-gnu/libpcre.so.3.12.1 7f0ce2216000-7f0ce2415000 ---p 0003c000 08:03 4726756 /lib/x86_64-linux-gnu/libpcre.so.3.12.1 7f0ce2415000-7f0ce2416000 r--p 0003b000 08:03 4726756 /lib/x86_64-linux-gnu/libpcre.so.3.12.1 7f0ce2416000-7f0ce2417000 rw-p 0003c000 08:03 4726756 /lib/x86_64-linux-gnu/libpcre.so.3.12.1 7f0ce2417000-7f0ce241e000 r-xp 00000000 08:03 4595204 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0 7f0ce241e000-7f0ce261d000 ---p 00007000 08:03 4595204 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0 7f0ce261d000-7f0ce261e000 r--p 00006000 08:03 4595204 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0 7f0ce261e000-7f0ce261f000 rw-p 00007000 08:03 4595204 /usr/lib/x86_64-linux-gnu/libffi.so.6.0.0 7f0ce261f000-7f0ce2621000 r-xp 00000000 08:03 4595069 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7f0ce2621000-7f0ce2820000 ---p 00002000 08:03 4595069 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7f0ce2820000-7f0ce2821000 r--p 00001000 08:03 4595069 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7f0ce2821000-7f0ce2822000 rw-p 00002000 08:03 4595069 /usr/lib/x86_64-linux-gnu/libXdamage.so.1.1.0 7f0ce2822000-7f0ce2824000 r-xp 00000000 08:03 4595065 /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0 7f0ce2824000-7f0ce2a23000 ---p 00002000 08:03 4595065 /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0 7f0ce2a23000-7f0ce2a24000 r--p 00001000 08:03 4595065 /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0 7f0ce2a24000-7f0ce2a25000 rw-p 00002000 08:03 4595065 /usr/lib/x86_64-linux-gnu/libXcomposite.so.1.0.0 7f0ce2a25000-7f0ce2a2e000 r-xp 00000000 08:03 4596119 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 7f0ce2a2e000-7f0ce2c2d000 ---p 00009000 08:03 4596119 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 7f0ce2c2d000-7f0ce2c2e000 r--p 00008000 08:03 4596119 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 7f0ce2c2e000-7f0ce2c2f000 rw-p 00009000 08:03 4596119 /usr/lib/x86_64-linux-gnu/libXcursor.so.1.0.2 7f0ce2c2f000-7f0ce2c36000 r-xp 00000000 08:03 4589482 /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 7f0ce2c36000-7f0ce2e35000 ---p 00007000 08:03 4589482 /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 7f0ce2e35000-7f0ce2e36000 r--p 00006000 08:03 4589482 /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0
Can you try building with debug symbols so the stack trace is usable? Also since it seems to be an allocation error, maybe running it under valgrind would be helpful.
Comment #96 has a stack trace with debug symbols included.
Somehow an OperationDetail is being created, added to its parent's list of children, then destroyed, while the pointer to it remains in the parent's list of children.
Ok, I figured it out. I ran into this back when I did "Change OperationDetail to not store complex objects in STL containers (#729139)". I have no idea why, but sigc::bind does NOT like it when you pass it a reference. Changing the references to pointers fixes it.
Created attachment 317254 [details] [review] 0001-Display-progress-during-resize-467925.patch
Created attachment 317255 [details] [review] 0002-Display-progress-for-mke2fs-467925.patch
Created attachment 317256 [details] [review] 0003-Display-progress-for-e2fsck-467925.patch
Thanks Phillip for the updated patches. The new patches in comments 102, 103, and 104 now no longer crash when applying operations. On kubuntu 12.04 I successfully tested the following: A) Create ext3 file system of 130 GiB shows progress bar growing from 0 to 100%. B) Check ext3 file system of 130 GiB shows progress bar growing from 0 to 100%. However, when I tried growing an ext3 file system from 2 GiB to 130 GiB, the resize step showed only the progress bar at 100%. It was similar with an NTFS file system, but this ran so fast that I couldn't be sure if the indicator was progressing. On another note, a small request for future patch sets is to include them in a single patch file. When I create my patch sets I use: $ git format-patch origin/master -n --stdout > mypatchset-vX.patch Thanks, Curtis
Created attachment 317343 [details] [review] Progress bars (v10) Hi All, As Curtis identified resizing ext2/3/4 progress bar goes to 100% and stays there while the command outputs more Xs. Resizing of NTFS progress bar work correctly. Attached is patchset v10. The only difference is changes in ext2::resize_progress() which corrects the progress bar. (Resize2fs outputs 40 dashes, 40 backspaces and then as progress is made 40 Xs. However the Gtk text widget doesn't interpret backspaces so PipeCapture::OnReadable() has to interpret backspace characters as moving the "cursor" on the line and writing new characters as replacing existing ones. Therefore what ext2::resize_progress() sees is always a progress bar of fixed length with dashes changing to Xs. The old code was just counting the length of the progress bar which was always fixed. The new code counts the length of the progress bar and the number of Xs in it to calculate the progress). Thanks, Mike
Thanks Mike for the updated patch set v10. I tested on kubuntu 12.04 and confirmed that resize2fs progress is now correctly reported with the progress bar growing from 0 to 100%. Over the next while I plan to test on several distros to see if any other problems arise. Curtis
Hi Phillip and Mike, Have you ever had that sinking feeling when you planned to run sudo rm -rf ./home but instead ran sudo rm -rf /home ^ Note leading dot is missing! when intending to delete a partial copy of the actual home directory? I realized my mistake quickly, but not before some damage was done. That's what I just did when preparing to test shrinking an NTFS partition. I've now just finished comparing files from a month old backup, and the recent partial copy of /home. I think I've recovered most everything, but only time will tell. It's been a long time since I've done something like this. The last time was with GParted testing as well. Anyways.... Following are my test results of patch set v10 from comment #106. The most extensive tests were performed on kubuntu 12.04, and a smaller set of tests will be later performed on various GNU/Linux distributions. Kubuntu 12.04 ------------- EXT2/3/4 TESTS 1) Grow 2 GiB ext3 partition to 129 GiB. SUCCESS - Progress bar moves from 0 to 100%. - Cancel -> Force Cancel selection does stop the running resize2fs operation 2) Check 129 GiB ext3 partition. SUCCESS. - Progress bar moves from 0 to 100%. - Cancel selection does stop the the running e2fsck operation 3) Format 129 GiB partition to ext2. SUCCESS. - Progress bar moves from 0 to 100%. - Cancel -> Force Cancel selection does eventually stop the running mkfs.ext2 operation (not immediately) * 4) Shrink 129 GiB ext2 partition to 2 GiB. SUCCESS - Progress bar moves from 0 to 100%. - Cancel -> Force Cancel selection does stop the running resize2fs operation 5) Create 129 GiB ext2 partition. SUCCESS - Progress bar moves from 0 to 100%. - Cancel -> Force Cancel selection does eventually cancel the running mkfs.ext2 operation (not immediately) * * For some reason the command is not immediately cancelled, but the resulting file system operation does appear to indeed be cancelled in that the created file system is invalid. NTFS TESTS 6) Grow 1 GiB ntfs partition to 149 GiB. SUCCESS - Process is too fast to measure with no time to cancel 7) 13% fill 149 GiB ntfs partition, empty, then shrink to 1 GiB. SUCCESS - Process still too fast to measure with no time to cancel (This is where I accidentally deleted some of my /home directory) I'll try testing on some other distros soon. Right now I feel a pressing need to make an immediate backup of my /home directory. :-) Curtis
Hi Curtis, Ouch. Definitely recommend an automated backup. I have a cron job run my backup daily to an old machine. Even if I completely wipe my desktop I loose at most 24 hours. If you want more details please ask. To slow down an NTFS shrink prepare a file system like this: 1) Create an NTFS (at least 10 GiB perhaps more) and mount at /mnt/1 2) Half fill with zeros (5 GiB in this case): dd if=/dev/zero bs=1M of=/mnt/1/zeros count=5120 3) Copy on lots of files: cd /mnt/1 cp -a ~/programming/c/gparted gparted-1 cp -a ~/programming/c/gparted gparted-2 ... 4) Remove zeros: cd /mnt/1 rm zeros Shrink file system to half size or less. This forces all the files to be moved below the half size mark where the zero file was. Works for all file systems as they all start allocating from the beginning. To make the resize take longer just copy on more files to be moved, making the initial file system larger if needed. Thanks, Mike
And for ext[234] you can use e2defrag to move files to the right to force resize2fs to have to move them back to the left ;)
Hi Phillip and Mike, Thank you for your tips on preparing file systems for resize tests. Following are more testing results. KUBUNTU 12.04 NTFS TEST ======================= A) Grow 1 GiB ntfs partition to 149 GiB. SUCCESS - Progress bar moves from 0 to 100%. - Cancel -> Force Cancel selection does eventually stop the running ntfsresize operation DISTRO TESTS ============ OPERATION WORKS AS EXPECTED WITH NO CRASHES DISTRO mke2fs e2fsck resize2fs ntfsresize ------------- ------ ------ --------- ---------- Debian 7 Yes Yes Yes Yes Debian 8 Yes Yes Yes Yes Fedora 12* Yes Yes Yes Yes Fedora 22 Yes Yes Yes Yes Fedora 23 Yes Yes Yes Yes openSUSE 13.1 Yes Yes Yes Yes openSUSE 13.2 Yes Yes Yes Yes kubuntu 12.04 Yes Yes Yes Yes Ubuntu 14.04 Yes Yes Yes Yes Ubuntu 15.10 Yes Yes Yes Yes * Old VM I tested out of curiousity for backward compatibility. Based on my testing, patch set v10 in comment #106 is ready to be committed to the git master branch. If there are no objections then I commit the patch set in the next day or so. Curtis
Thank you Phillip, Mike, and many others for your work to improve GParted with better progress indicators. Patch set v10 from comment #106 has been committed to the git repository for inclusion in the next release of GParted. The relevant git commits can be viewed at the following links: Display progress during resize (#467925) https://git.gnome.org/browse/gparted/commit/?id=57b028bb8e7c9fa5e750624f405cc268dfa3b4af Display progress for mke2fs (#467925) https://git.gnome.org/browse/gparted/commit/?id=baea186138cc08cac1f13f28300ca0f4b09ae16d Display progress for e2fsck (#467925) https://git.gnome.org/browse/gparted/commit/?id=ae434579e160ca2c306921b12d4211bf9abacef7
This enhancement was included in the GParted 0.25.0 release on January 18, 2016.