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
pgpcAkjMC9LpV.pgp
Description: PGP signature