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 [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
