Re: Bug#417622: NTFS-3g way too old, can cause data corrumption in rare conditions
Steve Langasek wrote:
> Michael,
>
> Please keep the Cc: list intact when replying.
>
> On Tue, Apr 03, 2007 at 11:01:00PM +0200, Michael Fritscher wrote:
>>> From my POV, the question is not whether ntfs-3g 1.0.0 should be included
>>> in
>>> etch (it won't be), but whether the risk of this data loss is significant
>>> enough that we should consider dropping ntfs-3g from etch altogether for
>>> the
>>> sake of our users' data. Since ntfs-3g didn't ship with any previous
>>> release, and has no reverse-dependencies in etch, it doesn't seem
>>> unreasonable to drop it from the release, and that seems to be in keeping
>>> with our policy of treating data loss bugs with the highest severity?
>
>> It killed already files for me and others.
>> It is mentioned in the forum, too:
>> http://forum.ntfs-3g.org/viewtopic.php?t=170&highlight=
>
>> Another problem is that unmounting was asyncron in these early versions,
>> which can cause data loss, too.
>
>> So I strongly advise to drop this package, if you don't want to update it.
>
> That's certainly persuasive to me. Adam, is there any hope of a targetted
> fix for these issues described, or are users really just safer if we drop
> the package from etch?
Just to add an extra data point, the release notes for NTFS-3G [1] indicate
that big-endian wasn't supported until the release after the one currently
in Etch (ie. 20061115 release has "fix: the code wasn't endian safe" and
I'm pretty sure the documentation in Etch mentions that it's not working on
BE machines)
So having a build of this version for PowerPC in Etch seems like it's asking
for trouble. Same for the other BE arches.
I've not tested this though, not having a scratch NTFS drive handy, which
is why I never got around to making a separate bug report out of this. It
may be that the warnings are largely paranoia.
--
Paul "TBBle" Hampson
Paul.Hampson@Pobox.com
Reply to: