GNOME Bugzilla – Bug 327685
Resize ntfs + create new FAT32 produces corruption/damage
Last modified: 2006-01-19 19:23:37 UTC
Please describe the problem: I have a single 55.88 GB harddisk in my laptop, with one NTFS partition for Windows. I wanted to install Gentoo on it, and to accomodate that I wanted to do two things: shrink the NTFS partition to exactly 12 GB (12288 MB), create a FAT32 partition at the end of the disk to share data between Windows and Gentoo, leaving exactly 20 GB unallocated between the NTFS partition and the FAT32 partition for Gentoo (which I intended to partition/format during the Gentoo install). Steps to reproduce: 1. Right-click on the NTFS partition, resize, set to 12288 MB, click OK 2. Create new partition in the now unallocated space, set free space preceding new partition to 20480 MB; 3. Use the partition-widget-thingy to resize the new partition to the end of the disk. (This seemed to leave about 6/7 MB at the end of the disk unallocated, so then I did: ) 4. Manually increase the new partition size using the input-box until it wouldn't allow me anymore. 5. Hit "Apply". Actual results: After the two operations (resize+create) were done, gparted rescanned the disk, and two items were listed: /fake/needwrite/dev/hda1 (warning sign) - unknown filesystem - 55.88 GB size - boot. /fake/needwrite/dev/hda2 - fat32 filesystem - 7.84 MB size (?!) - 0.14MB used - 7.71 MB unused Expected results: See description ;) Does this happen every time? Will confirm this in a moment, I just had to write this down quickly before I forgot what exactly I did. Other information: I'm using Gparted 0.1 from the 0.1 live-cd.
I can't reproduce this, although I haven't tried to reproduce this with an NTFS partition initially created by Windows, if that matters. It does seem now that the unallocated space (between the NTFS and new FAT32) reserved for Gentoo is slightly smaller then the projected 20 GB, after the operations are completed it indicates it is actually 19.99 GB (20473 MB). Sorry for wasting your time with this
Hi Hans, I've had quite some reports about errors while resizing a ntfs filesystem. The next release (hopefully somewhere next week) will provide far more detailed progressfeedback, hopefully this will help locating the source of the problems. I've also fixed some bugs with resizing partition, so with any luck this won't happen again. About the sizes.. partitions are rounded to cylinders, so the actual size might differ slightly from what you expected. Nothing serious though, usually we're talking about a max of 8 meg. The only thing i don't like is the fact the ntfs filesystem got corrupted. This is something i've never heard of before and should simply not happen. Did you manage to fix it and/or do you have any idea what may have caused it?
Thanks for your response! I didn't manage to fix the issue, though I didn't really try too hard since the NTFS partition didn't contain any valuable data. After gparted gave me the warning about the corrupt filesystem and my laptop failed to boot the old Windows installation I just started from scratch and tried to see if I could reproduce it (while writing this bugreport). I think the only difference between when the disk/filesystem actually got corrupted and my attempts to reproduce it, was that the in the latter case, the initial NTFS partition was made with gparted (as opposed to it being made by a Windows installation CD) and had no data on it. I don't need my laptop for anything at the moment so I am going to try to install Windows from scratch and see if I can reproduce the problem that way.
ok.. don't spend too much time on it now, as a new version of gparted is already in CVS. most likely it'll fix the issues with resizing. So its probably best if you wait for gparted-0.2 before doing any more experiments ;) Closing this one, please reopen or file a new bug if needed.