GNOME Bugzilla – Bug 673166
NTFS partition trashed when resized to minimum size
Last modified: 2020-11-13 10:40:50 UTC
I attempted to resize an NTFS partition to the minimum size gparted allowed (i.e., 0 free space). The process encountered errors halfway through the actual (non-simulation) run. Regrettably I didn't save the log, but I recall it mentioned failure to allocate MFT blocks. There were also some warnings about a non-positive free sector count, which gparted ignored. Perhaps gparted shouldn't allow / should warn users when attempting to shrink a partition to have zero free space, and leave at least a few MB for such occasions?
Did you use GParted Live? A log file would be most helpful. I tried to recreate this problem, but in the situations I tested the NTFS partition was able to be successfully resized to the smallest value shown by GParted. GParted relies on tools from the ntfs-3g project (previously ntfsprogs) to determine the smallest size that a partition can be resized. To determine the smallest size for resizing, GParted uses the following command: ntfsresize --info --force --no-progress-bar /path-to-ntfs-partition And looks for the value near "resize at XXXXXX bytes". Further GParted also tries a test run of the resize command with the "--no-action" option before performing the actual resize. In order to pursue this problem further we need at least a log file, and ideally a set of steps to recreate this problem. Can you try to recreate the problem?
Sorry, unfortunately I can't provide a log file, and I have since repartitioned that hard disk entirely. The problem would not have been reproducible either way, since the NTFS partition was corrupted and gparted reported filesystem errors. The test run had completed successfully. I used gparted live 0.12.0-5.
It is unfortunate that you encountered this problem that trashed your NTFS file system. Without a test case with specific details, we don't have much to go on. ;( Would you be able to try to create a new test case that demonstrates the problem?
I can't imagine how I could recreate a test case for this situation, since the problem was likely due to specific factors of the data layout of the affected partition, which was permanently lost from the failed resize. I don't think creating an NTFS partition and throwing a few files on it will be enough. Two suggestions, if I may: 1) Leave e.g. 1 MB (or 0.1%) of free space when shrinking partitions. This should be fine for casual users. 2) If an error occurs during the actual (non-pretend) run, add an interface option to submit the log to bugzilla, or otherwise somehow recorded online.
The suggestion to leave a small amount of free space when shrinking partitions sounds like a reasonable compromise. Another way to approach this would be to warn users if they try to shrink a partition beyond a certain percentage, perhaps 5%. If this is something you would like to try your hands at to enhance GParted then we would be happy to review a patch. :-)
Created attachment 211007 [details] [review] Warn user when resizing a partition to less than 1% free space. OK, how's this?
Wow that was quick! :-) I plan to review this in the new day or so. Right now I am busy with preparation for the next release of GParted (0.12.1 on April 9, 2012.)
This enhancement is on my radar for the next release of GParted. Development Plans for the Next Release of GParted (0.13.0) http://gparted-forum.surf4.info/viewtopic.php?id=16479 From initial testing I discovered some trailing whitespace added by the patch that should be removed. The code compiled and ran, but I have not extensively tested this patch yet. I plan more testing in the next month or so.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).