On 10/10/2007, Christopher Brown wrote:
> On Wed, 2007-10-10 at 23:02 +0200, Thorsten Leemhuis wrote:
>
> > There are two ntfs implementations. One is old, crufted, and poorly
> > maintained.
Not sure what is to blame here but Thorsten didn't write that, Spot did.
>
> Sorry but that is bullshit. Old and crufted aren't very good technical
As I mentioned previously, the kernel driver and ntfs-3g have the same
source base. When I developed ntfs-3g then I noted the potentially serious
problems in the kernel (e.g. in truncate). I also mentioned them to Dave
Jones. I never got a reply for any of my emails.
You're surprised by that?
Recently a buffer overflow
was discovered (Andrew Morton fixed it), driver hangs during logfile reset
(maintainer made a patch).
I'm sorry I can't see the relevance of this as an argument. Both issues were fixed, one by the maintainer. What's the problem?
It seems as the kernel evolves, the kernel NTFS driver isn't adjusted as
Miklos Szeredi does for the FUSE kernel module, so the kernel side of the
NTFS-3G driver can stay safe, deadlock and corruption free, no need to
worry about it. He is also extremely responsive both design and
troubleshooting discussions and quality coding wise. He is employed by
Novell and allowed to work on FUSE in a certain amount of his work time.
I'm mad keen to see figures of enterprise installations running FUSE over kernel drivers. I mean _really_ keen.
> arguments and poorly maintained is simply untrue.
The maintainer has been working for a non-Linux company since 2005 and from
that point his open source contribution and leadership role is minimal.
Here we agree.
I've worked with him 4 years when it was decided finally a year ago that a
partial fork is needed to ensure driver reliability and maintainability.
Partial? Could you define this? Please remember that I was/am a member of the linux-ntfs project and although my contribution was only in the package department for Rich Russon when he was around, there was nothing to indicate you were intending to fork. and even then there was no real reason given in your announcement that you were doing it for the above purpose.
For example we (linux-ntfs team at that time) were reported that some ntfs
utilities made Vista unbootable. The reason was found and fixed a year ago,
still the official bugfix was released only 10 days ago. The serious fix
was sitting in the CVS for a year.
Whats wrong with bugging Linus to get it applied then? I'm having a hard time believe crucial fixes sit in cvs simply because someone wont write an email saying "Linus, please apply...". If Anton wont sign off (or comment) then I'm inclined to agree the driver is dead in the water but it doesn't look like this happened.
Obviously everybody thinks differently what is "poorly maintained". For me
the above is one sign, amongst several others.
> If this boils down to "It doesn't have write support, bwaaaaaaaah" then
> "poorly maintained" isn't much of one either. The reason there have been
> so few git commits is because it works fine in the state that its in and
> as I explained, the core developer is focused mainly on the new driver
> which, license debates aside, will be released in about a year.
In 2005, we were offered NTFS code in favour of letting a company use and
dual licence what we have developed. Then it became 2006 then the story
changed a bit then the date was 2007 and then 2008.
True and I agree that actions speak louder than words. My original point was that I believe Fedora should ship with the ntfs kernel driver enabled, mount.ntfs should actually be named mount.ntfs-3g and to try and point out the difference between functionality and stability - quite important where filesystems are concerned.
> Dave asked me for my opinion, and I said that we shouldn't ship
> something that's not recommended by one of its authors, and has no
> real maintenance upstream:
>
> http://ntfs-3g.org/about.html
It would probably benefit from having any post-fork detail removed. As it currently stands it might be interpreted that the reason for the fork was the the kernel driver was not going to be released until 2008. I'm still at a loss as to why you forked but then I was not privy to conversations that went on behind the scenes perhaps.
> who spat the dummy and went off and created ntfs-3g when he could have
> merged it with ntfsprogs.
My apologies, this was rude.
Here is my original announcement:
http://sourceforge.net/mailarchive/message.php?msg_id=Pine.LNX.4.21.0607141859080.31588-100000%40mlf.linux.rulez.org
I did the work as a long time Linux-NTFS project member. There wasn't
__anything__ to merge. The work itself was Linux-NTFS, so in fact I __did__
merge it when I published it. The code could have been just used without
any change. I was the only one working on write support and there wasn't
really anything to merge with because they were already included.
After two-three months later the project still wasn't going the way it
should have hereby the fork was made.
The announcement came without warning - this is my issue. It would've been nice to have seen a "I'm thinking of forking because of a, b, c etc. Can anything be done?". So yeah, I'm a little sad that the project split and now confusion reigns.
> It actually has nothing to do with the kernel driver.
As I wrote, it has quite a lot, in fact.
Please stop editing the posts like this; it is really bad form. NTFS-3g is separate and distinct from the kernel driver. One is not reliant on the other but perhaps you misunderstood me.
Please don't take this as criticism of ntfs-3g - I think it was a long time (too long) in coming and enables lots of interesting things to happen. Keep up the excellent work - I'm all in favour of choice which is what the original argument was all about.
Cheers
Chris
--
http://www.chruz.com
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
