On Saturday 11 November 2006 04:21, Steve Langasek wrote: > I'm having a hard time distilling the information in these bug reports > into a summary of what each bug is actually about or what the current > status is. I don't find that at all surprising as it cost me a lot of hours to get get the info collected, the issues identified and, in the case of ntfsprogs, upstream convinced [1]. > Isn't it the case that there is a workaround in place > now in the Debian packages that prevents resizing of NTFS filesystems > if they're detected as belong to a recent version of Vista? s/a recent version of// > Is this workaround implemented somewhere *other* than the linux-ntfs > package? Yes, it is implemented in partman, not ntfs-resize. Partman now blocks resizing of any partition containing the Vista OS (or rather: the files that are used to boot Vista). It does not block resizing data partitions. The upstream maintainer of ntfsprogs only recently was convinced that the issue is real. He has said he wants to block resizing Vista partitions, but I don't know if that has been implemented yet. It is certainly not yet in Debian. There is some uncertainty if the ntfsresize issue only affects Vista OS partitions or if it also extends to (Vista) data partitions. Note that I have also seen two recent reports about issues with corruption of XP NTFS partitions (#394963), though that seems unrelated to resizing. [this quote moved up a bit] > But again, I don't understand how libparted has a bug separate from the > linux-ntfs one. [quote from message Saturday 11 November 2006 04:38] > I'm not sure there's any reason this bug would be specific to NTFS > partitions, though, is there? libparted causes the starting sector of the partition to change, thus making the physical partition invalid. This bug is indeed not even strictly related to Vista partitions, but other partitions seem to get created aligned on cylinder boundaries by default (or we'd have seen a lot more bug reports). ntfsresize somehow causes an corruption of internal consistency (probably some meta-data about the partition is saved somewhere and is not updated after the resize) that is expected by the Vista bootloader. > Your rationale for ignoring 380226 also makes no sense to me; if this > bug manifests in the installer, isn't that still a data loss bug that > we need to fix before release? There are also two other packages in > testing, gparted and mindi, which use libparted, so if there's a > dataloss-causing bug in libparted I don't see that it's ignorable even > if we did accept an argument that data loss in the installer is ok > (which I don't). There are a few reasons why I thought we could tag the libparted issue etch-ignore: 1) it is not a regression from Sarge 2) there has been precious little attention to the issue from the maintainers of parted even though the BR was already 3 months old; I talked to Otavio today though and he promised to start on it 3) the chance that people will resize a partition not aligned on a cylinder boundary outside d-i seems pretty slim 4) it is not dataloss is the strict sense: you can recover by changing the staring sector back to its old value (the trick is how to find out what the old value was...) Resizing a partition that is not on a cylinder boundary is scary anyway: fdisk will also do the wrong thing unless you remember to change the units it uses from cylinders to sectors (using its 'u' command). I did check parted itself and that does the right thing as it asks for the starting sector (IIRC). I have no idea about gparted and mindi. If you feel the libparted bug should be fixed before the release, that is perfectly fine by me. However, it really is an upstream issue and there probably is a very good reason why that alignment check was originally added. I would not want to just apply Bas' patch and hope for the best. > Can someone who understands what's going on with these bugs please fix > up the bug titles so that they're an accurate summary, to help the rest > of us figure out which bits of information in the bug log are relevant > to the current bugs? IMHO the bug reports are pretty clear. They all have the same origin: /me having problems booting vista after resizing its NTFS partition, but have diverged at some point to deal with the separate issues. There is no actual bug in partman, but the two other bugs makes a workaround there necessary until the other two issues are fixed, hence the blocks. It could be argued that partman should also check if a partition in an msdos partition table is aligned on a cylinder boundary before allowing to resize, but I feel the risk of that happening for non-Vista partitions is small enough to ignore it (people should always backup their data before resizing anyway, right?). If someone would supply a patch for that I'd apply it though. The BR against ntfsprogs has grown huge, mostly because it took a lot of effort to convince the upstream maintainer that there really was an issue. I am keeping track of all three BRs, so feel free to ask me for additional info if you need it. Cheers, FJP [1] I must say though that without the help from the ntfsprogs upstream I would never have gotten the issues identified at all.
Attachment:
pgpv_8xVbTa4y.pgp
Description: PGP signature