After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627199 - Warning when moving partition
Warning when moving partition
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: application
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2010-08-17 18:32 UTC by ghelyar
Modified: 2010-09-23 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gparted details log (25.85 KB, text/html)
2010-08-18 01:11 UTC, ghelyar
Details
Screen shot of GParted warning that partition move could break boot process. (25.64 KB, image/png)
2010-09-01 20:04 UTC, Curtis Gedak
Details

Description ghelyar 2010-08-17 18:32:18 UTC
I chose to resize a partition, to make more space at the *end* of it. I did this just by changing the "space after" box and ignoring the "size" and "before" boxes. I thought this would just resize it, and take a matter of seconds.

I was quite shocked when it decided to move the entire partition to the left (even though it was the first partition and supposedly at the start of the drive) and took hours. I couldn't even hit cancel once it had started because it would have corrupted it. I assume this was because of cylinder boundaries or something like that, but the reason was not clear.

Even the list of tasks only showed one operation, not a separate move and resize.

There should either be a warning dialogue box specifically when a long move operation is going to take place (separate to any generic "changing your partitions could damage your data" warning) or the "move" option should be separated from "resize", as one operation is almost trivial while the other is not.
Comment 1 ghelyar 2010-08-17 18:37:17 UTC
To clarify, it was an almost empty file system with no fragmentation (no files at the end of the file system) and I was shrinking it to create unallocated space after it, not expanding it to add more space to the file system itself. I have done this before plenty of times and it usually only takes seconds to shrink because it does not have to be moved at all.

If I had known it would move it, I would have created the unallocated space at the start of the disk instead of the end. That was what I was trying to avoid by putting it at the end.
Comment 2 Curtis Gedak 2010-08-17 18:41:27 UTC
Which version of GParted were you using?

Versions of GParted prior to 0.4.4 had this problem as described in the following bug report:
Bug #571151 - gparted moves partition to the left even if unneeded
Comment 3 ghelyar 2010-08-17 18:51:43 UTC
It seems to be related to, but not a duplicate of

https://bugzilla.gnome.org/show_bug.cgi?id=432525
https://bugzilla.gnome.org/show_bug.cgi?id=571151
https://bugzilla.gnome.org/show_bug.cgi?id=564645
etc

Obviously other people have had the same trouble realising that it is going to perform a move as I have had.

I am not complaining about the behaviour but rather suggesting that it should be made much more obvious when it is about to happen, because it is currently only very clear when you start the operation.

I believe it is version 0.5.1. It's the Ubuntu 10.4 live CD. Unfortunately because it is still processing the drive, and I didn't make an image of the drive to repeat the process afterwards, I am unable to re-test it with a newer version.

I just assume it hasn't been fixed because I made the same mistake years ago (and worse, cancelled it early, corrupting the whole file system) but never reported it, putting it down to my own stupidity.
Comment 4 Curtis Gedak 2010-08-17 23:02:02 UTC
When the resize/move operation is complete, please save the gparted_details.htm log file and post it here.

With versions 0.4.4 and higher of GParted, the only way a move is supposed to be invoked is if the "Free Space Before (MiB)" value is changed.

Did you perhaps change this value?

If this is not the case then you may have found another bug and I will need your help to try to track it down.

As for an indication that a move is going to occur, the operation pending list should show something like "Move and shrink...".

There is also an existing bug report regarding notification of partition moves having the potential to break the boot process.
See bug #616694.
Comment 5 ghelyar 2010-08-18 01:11:25 UTC
Created attachment 168161 [details]
gparted details log
Comment 6 ghelyar 2010-08-18 01:26:42 UTC
All I did was change the "after" value to 20480, and click the focus in the "size" box so that it would adjust the other values accordingly. Perhaps it changed the "before" value and I didn't notice, but I did not change it myself and as far as I know it should have only changed the "size" value.

I was attempting to create a 20gb partition at the end of a 500gb drive for a Debian dual boot (previously formatted by Windows 7 to use the full disk for NTFS)


The list of tasks did say "move and resize" but because all I did was change the space after, and only one item came up in the list of tasks, and the actual button to resize is called "move/resize" anyway, I didn't read it carefully or think much of it before clicking the button. This is why I asked for it to be more obvious in some way. Perhaps "move" should be listed as a different task to "resize" or something simple like that.

By the time I noticed, it said moving and that it had hours left. If you click the "+" to expand the "moving to the left" to get more details, it says it is doing a "read only check", which implies you can cancel there without damaging the drive, but you can't. That's where I made the mistake of cancelling last time.


I don't know about breaking the boot process, I'm doing this on a data drive, not a drive that is currently being booted from. I planned on booting from it after installing Debian to it but if it didn't work I probably would have just put it down to the /boot partition not being near the start of the drive anyway.
Comment 7 ghelyar 2010-08-18 01:43:01 UTC
RE: breaking the boot process

I've just booted Windows 7 back up and it had to perform a chkdsk on boot for that drive though, even though it was just a data drive and not the system boot drive.

After the chkdsk was completed, the drive was accessible but a "bootsqm.dat" file is present on the drive where it was not before. I don't know if chkdsk left this behind or it's a product of modifying the filesystem during the move.

This may just be down to NTFS version or something though. When Vista first came out and NTFS went from 4 to 6, Vista would have trouble with drives marked as NTFS 4 after they were accessed from Linux. I had to use the latest version of ntfsfix to get it working again when this happened.
Comment 8 Curtis Gedak 2010-08-20 15:36:30 UTC
I have confirmed that typing in a smaller value in the "Free space following (MiB)" and then clicking on the size box will indeed add the extra space to the "Free space before (MiB)" box.  This is as designed to operate.

Better notification that a move is to be performed is certainly desirable.  This is currently requested in Bug #616694.

Since this bug report has a more applicable title describing the problem, I will close bug #616694 and leave this one open to track the need for a move warning dialog box.
Comment 9 Curtis Gedak 2010-09-01 20:04:27 UTC
Created attachment 169287 [details]
Screen shot of GParted warning that partition move could break boot process.

A dialog box warning that a partition move has been queued has been committed to the gnome git repository for inclusion in the next release of GParted (0.6.3).

The relevant git commit can be viewed at the following link:
http://git.gnome.org/browse/gparted/commit/?id=aa14b25f1b1cf2eeaff8ea18b3ee1a2c78a221b1
Comment 10 Curtis Gedak 2010-09-23 17:03:56 UTC
The enhancements to address this bug report have been included in GParted 0.6.3 which was released on September 23, 2010.

Closing this bug report.