severity 379628 important
thanks
Just tested with 1.13.1, but it turns out the problem is not in=20
ntfsresize.
The root of the problem seems to be how the Vista installer created=20
partitions. Yuval was correct: using default cylinder based partitioning,=20
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=20
was correct.
I would suggest very strongly to document this aspect of resizing an NTFS=20
partition better and warn users of this possible cause of data loss.
Neither the upstream FAQ [1] nor the documentation included with the=20
package (manpage or /usr/share/doc) currently document this.
Even stronger: the example in the FAQ uses cylinders rather than sectors=20
just like I did!
The troubleshooting part of the FAQ does explain about starting sector,=20
but does not explain the difference between cylinders based and sector=20
based partitioning. Most users will react the same as I did: "but the=20
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=
=20
properly documenting this deserves that severity.
With this information, I will try to see if we can fix this issue in the=20
Debian Installer. Thank you for helping find the cause of the issue.
Cheers,
=46JP
[1] http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html
|