GNOME Bugzilla – Bug 616694
FAQ: gparted not safe for vista/7.
Last modified: 2010-09-01 20:06:55 UTC
http://gparted.sourceforge.net/faq.php "Is it safe? in short, yes it is safe." this is no longer true for Vista/7. it is not safe for Vista/7. you should put in a caveat that says "moves and resizes do not work without an OS Repair under Vista/7. http://www.howtogeek.com/howto/windows-vista/using-gparted-to-resize-your-windows-vista-partition/ what the article didn't say is that a repair also necessitates a subsequent software packages reinstall. this that article still true? if this is accurate, people need to be warned ahead of time and as much as possible. or a fix needs to be put in place.
Thank you Jim for bringing to my attention the need to raise awareness of this issue. I have added the following note to FAQ point #2: NOTE: If you move a partition that is used in the operating system boot process (for example the C: drive in Windows), then the operating system might fail to boot. To fix this problem you will need to repair the boot configuration. See FAQ #9 for Windows and FAQ #10 for Linux/GRUB. I have tested moving the C: drive with Windows XP and in each case Windows XP was able to boot after the move. I understand that the boot process was changed in Vista and now requires manual intervention to repair the boot configuration. To my knowledge only the boot configuration needs to be fixed and no software packages need to be reinstalled. Does the above update to the FAQ raise this issue to your satisfaction, or is there different wording that you would prefer?
regarding the "NOTE:", it's not just move, it's move or resize. a while back gparted was doing resize operations on startup I noticed. so if that hasn't changed, the only OS it's safe on is anything older than vista. it's not safe on linux. it's not safe on vista. it's not safe on 7, which is what nearly everybody has now. could the program be fixed and the "safe:yes" be turned to "safe:not with all operating systems (see Note)"? if you use gparted in a vista or 7 box, it's not going to boot anymore. I don't call that "safe".
the resize on startup thing was only on certain partitions, such as EISA Config partitions. it would resize/convert them from 2GB partitions to 4GB FAT partitions. odd bug. I think it has since been fixed, but I have nothing more to test with now that my system has been upgraded.
Jim, thank you for clarifying your position. I believe you have asked several questions in the above two comments. In this comment I will respond to the questions regarding move/resize/convert. I will respond to the question of "safe" in a later comment. On startup, GParted will scan the computer for devices, partitions on the devices, and information about file systems on the partitions. Several different commands are used to gather file system information depending on the type of file system. To my knowledge the latest version of GParted does not modify the disk when using these commands. RESPONSE TO COMMENT #2 Jim, you mentioned that you observed GParted performing resize operations on startup. To determine the number of used and unused sectors in an NTFS file system, GParted uses the following command: ntfsresize --info --force --no-progress-bar /path -i, --info By using this option ntfsresize will determine the theoretically smallest shrunken filesystem size supported. Most of the time the result is the space already used on the filesystem. Ntfsre‐ size will refuse shrinking to a smaller size than what you got by this option and depending on several factors it might be unable to shrink very close to this theoretical size. Although the integrity of your data should be never in risk, it’s still strongly recommended to make a test run by using the --no-action option before real resizing. Practically the smallest shrunken size generally is at around "used space" + (20-200 MB). Please also take into account that Windows might need about 50-100 MB free space left to boot safely. This option never causes any changes to the filesystem, the par‐ tition is opened read-only. -f, --force Forces ntfsresize to proceed with the resize operation even if the filesystem is marked for consistency check. Please note, ntfsresize always marks the filesystem for consis‐ tency check before a real resize operation and it leaves that way for extra safety. Thus if NTFS was marked by ntfsresize then it’s safe to use this option. If you need to resize several times without booting into Windows between each resizing steps then you must use this option. -P, --no-progress-bar Don’t show progress bars. The above command with the --info option does not write any changes to the disk. It is used only to gather information about the NTFS file system. QUESTION 1: Perhaps you saw this ntfsresize command running on an NTFS file system when you mentioned "a while back gparted was doing resize operations on startup I noticed"? Regarding the comment "it's not just move, it's move or resize", I think you might be referring to an earlier problem where resize operations would also become a move operation. This was reported in bug #571151 - gparted moves partition to the left even if unneeded. This problem was fixed in GParted version 0.4.4. QUESTION 2) Was it the above bug #571151 in earlier versions of GParted that you were referring to when you mentioned "it's not just move, it's move or resize"? RESPONSE TO COMMENT #3 You mentioned that you noticed GParted was doing "resize/convert" operations on startup on EISA Config partitions converting them from 2 GB partitions to 4 GB FAT partitions. On startup, GParted runs the following command on FAT file systems to determine the number of used and unused sectors: dosfsck -n -v /path-to-disk-partition -n No-operation mode: non-interactively check for errors, but don’t write anything to the filesystem. -v Verbose mode. Generates slightly more output. Prior to version 0.4.8, GParted used the -a flag: -a Automatically repair the file system. No user intervention is necessary. Whenever there is more than one method to solve a problem, the least destructive approach is used. The change from the "-a" flag to the "-n" flag is described in bug #605175. QUESTION 3) Perhaps you saw one of the earlier versions of GParted modifying the disk with a file system check when you mention "it would resize/convert them from 2GB partitions to 4GB FAT partitions"? To summarize the above: - I know of no situations where GParted modifies data on the disk during startup using the current version (0.5.2). The only time GParted will modify the disk is when instructed by a user to do so. - Only move operations (which change the starting sector of a partition) might adversely affect the boot configuration. Resize operations (which grow a file system from the end of the partition) should not impact boot configuration. - I will respond to the "safe" question in a later comment.
RESPONSE TO "SAFE" QUESTION (In reply to comment #2) > could the program be fixed and the "safe:yes" be turned to "safe:not with all > operating systems (see Note)"? > > if you use gparted in a vista or 7 box, it's not going to boot anymore. I > don't call that "safe". Jim, I think you have a good idea here. Keeping the user informed is most important so that they can make educated decisions. Using the word "safe" is too vague. By this I mean that the word "safe" does not provide the user with enough information on whether to proceed or not. For example: Moving a partition might not be safe. This message does not provide an adequate description of the problem for the user to make an informed decision. I believe something similar to the following would be better: Moving a partition might cause your operating system to fail to boot. You can learn how to repair the boot configuration in the GParted FAQ. This latter description provides the user with enough information to know that if they move a partition, their computer might fail to boot. It also indicates how to go about resolving this problem should it occur. My thoughts are to modify the program such that if a user places a move partition operation in the queue, the program will display a dialog box indicating the potential problem similar to the message above. Have I interpreted your idea correctly? If not, then would you be able to state your idea in a different way?
Oops, my mistake on version number. In comment #4, the following sentence: Prior to version 0.4.8, GParted used the -a flag: should have read Prior to version 0.5.1, GParted used the -a flag:
it sounds good to me. thank you for clarifying that. I reported a bug a year ago regarding the FAT EISA config partition "conversion" problem, which was probably a fsck gone awry. the next time I looked at the partition, it was 4GB instead of 2GB or something like that, and it surprised me. either that or it was during a copy process and it shouldn't have worked out that way. it's been so long I don't remember the details anymore, and my partition is now 4GB. but it seems to still work, so I think I'm OK. weird partition. doesn't show up under windows as a drive letter. came standard with the old 2004 Dell 4600. Bug 434700.
Closing this bug because the FAQ has been updated regarding potential problems when moving Windows 7 boot partitions. This addresses the title of this bug report. Bug #627199 (Warning when moving partition) follows up with the need for a warning when a partition is to be moved.
A dialog box has been added to gparted to warn that moving a partition might break the boot process. https://bugzilla.gnome.org/show_bug.cgi?id=627199#c9