severity 379628 important
thanks

Just tested with 1.13.1, but it turns out the problem is not in 
ntfsresize.

The root of the problem seems to be how the Vista installer created 
partitions. Yuval was correct: using default cylinder based partitioning, 
the starting sector _is_ indeed changed from 2048 to 63.

Before deleting/creating the partition:
   /dev/sda1   *           1        2550    20481024    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *        2048    40964095    20481024    7  HPFS/NTFS

After deleting/creating the partition:
   /dev/sda1   *           1        1217     9775521    7  HPFS/NTFS
after toggling display/entry units with 'u':
   /dev/sda1   *          63    19551104     9775521    7  HPFS/NTFS

After recreating the partition with start sector 2048, the NTFS partition 
was correct.

I would suggest very strongly to document this aspect of resizing an NTFS 
partition better and warn users of this possible cause of data loss.
Neither the upstream FAQ [1] nor the documentation included with the 
package (manpage or /usr/share/doc) currently document this.
Even stronger: the example in the FAQ uses cylinders rather than sectors 
just like I did!
The troubleshooting part of the FAQ does explain about starting sector, 
but does not explain the difference between cylinders based and sector 
based partitioning. Most users will react the same as I did: "but the 
start is still at 1, so that cannot be the problem".

Reducing the severity of this bug report to from RC to important as I feel 
properly documenting this deserves that severity.

With this information, I will try to see if we can fix this issue in the 
Debian Installer. Thank you for helping find the cause of the issue.

Cheers,
FJP

[1] http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

Attachment: pgpcAkjMC9LpV.pgp
Description: PGP signature

Reply via email to