1 Topic by paulhar

  • paulhar
  • New member
  • Offline
  • Registered: 2007-01-02
  • Posts: 3

Topic: ntfs resize bug

SATA RAID-0 based machine under Ubuntu 6.06. Resizing a Windows XP partition.

Did an apt-get install dmraid to get the RAID bits going
Ran gparted (after checking it was the most recent version of gparted and ntfsprogs) and proceeded to shrink my NTFS partition from 190GB to 140GB - 99GB of data so 90GB free.

After finishing gparted showed that the partition side was now 140GB and the free space was still 90GB!

Not panicing, rebooted back to Windows and found that XP won't boot - blue screens after a while.

Rebooted back into Ubuntu, dmraid, then looked at the ntfsprogs page to see what they recommended. A quick fdisk (delete the NTFS, recreate the NTFS partition max size) and an ntfsprogs check to make sure the filesystem was ok and I'm back to where I started.

Then manually ran the process through ntfsprogs - everything seemed to work fine. manually deleted the ntfs partition, recreated it smaller, and rebooted. Windows works fine.

ntfsprogs site recommends I contact you to warn that there is a problem. Looking at the output of gparted as it started the ntfs bits I noticed it doing lots of --force - probably not a great idea. Also I noticed during my manual process that the partition table isn't refreshed by the kernel without a dmraid -an && dmraid -ay. If gparted is just expecting the kernel to refresh the table then it's faulty.

Anyway - no harm done, I'm repartitioned, but thought you should know there seems to be a problem.

I can provide output of dmesg, versions of ntfsprogs, dmraid etc if needed.

Regards

Paul

2 Reply by LarryT

  • LarryT
  • Moderator
  • Offline
  • From: France (Bretagne)
  • Registered: 2006-07-31
  • Posts: 1,230

Re: ntfs resize bug

Happy that you fix your problem, but ....
It 's shame that you didnt backed up the details file ! How do you want we try to fix something with nothing ?

Larry
GParted-project Admin
Former GParted-LiveCD maintainer (2007)

3 Reply by paulhar (edited by paulhar 2007-01-03 11:53:14)

  • paulhar
  • New member
  • Offline
  • Registered: 2007-01-02
  • Posts: 3

Re: ntfs resize bug

LarryT wrote:

Happy that you fix your problem, but ....
It 's shame that you didnt backed up the details file ! How do you want we try to fix something with nothing ?

It's hard to back stuff up when booted from a livecd - not impossible but a bit hardar smile Plus I wasn't planning on reverting everything back just to capture the output again...

I guess the point of my mail was that having quickly reviewed the nfts.cc code there is return code checking but no double-check that the ntfsresize occured; before editing the partition table do another ntfsresize --info check to make sure that it really did shrink since in my case for some reason it didn't - a quick check to make sure that the "Current volume size" has shrunk to the expected amount should suffice? The ntfsresize FAQ calls that an optional step but I believe it should be mandatory in this case?

Also --force shouldn't be used for the actual resize - if there is a flagged consistancy problem then the user should resolve that before things are made worse by fiddling with the filesystem.

The code seems to set the same --force flag twice as well... Glib::ustring str_temp = "ntfsresize -P --force --force " + partition_new .get_path() ;   - according to the man page there isn't a requirement for a second --force.

For me the resize code should do:
1) Consistancy check using --info  (--force if this is the second resize being performed on the same partition in the same gparted session), Abort if the check fails.
2) Simulate resize (--force if this is the second resize...)
3) Resize (--force if this is the...)
4) Consistancy check using --info --force settings. If this fails, or if the size hasn't shrunk then abort.
5) Return success so the partition table can be rewritten.

4 Reply by plors

  • plors
  • Member
  • Offline
  • Registered: 2006-07-31
  • Posts: 401

Re: ntfs resize bug

Hi bit pressed for time, but the second --force is to avoid the 'are you sure' question wink

You are right about the check for a succesfull shrink before modifying the partitiontable. it has been on the TODO for a while now, but sometimes life is very, very busy smile