|
From: Frans P. <el...@pl...> - 2006-07-25 12:21:08
|
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 |
