Bug#379835: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important
On Thu, Oct 12, 2006 at 07:59:34AM +0200, Frans Pop wrote:
> There are currently three RC bugs open related to the resizing of NTFS 3.1
> partitions as created by Windows Vista.
> - #379628: ntfsresize - upstream bug, but disputed; I can reproduce it
> reliably though; needs confirmation by someone else
> - #380226: libparted - clear issue, recently further traced during BSP in
> Utrecht; needs attention from Debian maintainer and upstream
> - #379835: partman - no bug in partman itself, but the result of the two
> listed above (blocked by both)
> I have today uploaded a version of partman-partitioning that includes a
> check for NTFS 3.1 partitions and refuses to resize in that case; earlier
> NTFS partitions (NT, XP, 2000) should still be resizable.
> As partman is now "safe" I am downgrading #379835 to important.
> For #380226 I recommend tagging it 'etch-ignore'.
> The reason I think it's safe to do that is that it may only manifest
> itself in the installer. I'm unsure where else and how libparted is used
> I have tried resizing an NTFS 3.1 partition using parted, and that
> correctly left the starting partition unchanged, so parted is unaffected.
> IMO #379628 should not be ignored for Etch and it would be nice if someone
> else would try to either reproduce the bug or prove me wrong. There is
> plenty of information in the BR for that. Without a working ntfsresize,
> resizing NTFS 3.1 partitions is a no-op anyway.
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.
(Having two bugs with the same bug title doesn't help matters any. :/)
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? Is this workaround implemented
somewhere *other* than the linux-ntfs package?
If linux-ntfs now correctly avoids resizing filesystems that it can't ensure
are usable afterwards, I would argue that 379628 should be downgraded
(though of course it would be great to have it fixed in time for etch!).
But I guess you've put this workaround in partman-partitioning, not in the
package that contains the actual bug? If linux-ntfs does not yet have such
a workaround in place, let me know and I'll try to work on providing one.
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). But again, I don't
understand how libparted has a bug separate from the linux-ntfs one.
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
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.