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 673166 - NTFS partition trashed when resized to minimum size
NTFS partition trashed when resized to minimum size
Status: RESOLVED OBSOLETE
Product: gparted
Classification: Other
Component: application
0.12.0
Other Linux
: Normal normal
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2012-03-30 12:27 UTC by Vladimir Panteleev
Modified: 2020-11-13 10:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Warn user when resizing a partition to less than 1% free space. (3.19 KB, patch)
2012-03-31 00:26 UTC, Vladimir Panteleev
none Details | Review

Description Vladimir Panteleev 2012-03-30 12:27:48 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?
Comment 1 Curtis Gedak 2012-03-30 17:45:13 UTC
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?
Comment 2 Vladimir Panteleev 2012-03-30 17:49:10 UTC
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.
Comment 3 Curtis Gedak 2012-03-30 17:54:20 UTC
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?
Comment 4 Vladimir Panteleev 2012-03-30 18:00:20 UTC
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.
Comment 5 Curtis Gedak 2012-03-30 18:06:58 UTC
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.  :-)
Comment 6 Vladimir Panteleev 2012-03-31 00:26:21 UTC
Created attachment 211007 [details] [review]
Warn user when resizing a partition to less than 1% free space.

OK, how's this?
Comment 7 Curtis Gedak 2012-03-31 22:29:10 UTC
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.)
Comment 8 Curtis Gedak 2012-04-10 18:36:29 UTC
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.
Comment 9 André Klapper 2020-11-13 10:40:50 UTC
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).