NTFS driver (was: ReactOS GPL vs. proprietary drivers)
lace at jankratochvil.net
Tue Oct 21 14:37:53 CDT 2003
On Tue, 21 Oct 2003 21:05:57 +0200, Szakacsits Szabolcs wrote:
> On Tue, 21 Oct 2003, Jan Kratochvil wrote:
> Most of them
> is read-only but if you know how to read, sure you can write as well.
Block allocation bitmaps (or Btrees or whatever) do not need to be understood
for writing. You can ignore a zillion of unknown data fields during read (such
as checksums). You can read the whole hashtables while not understanding the
hash function. You do not need to know maximum sizes of data structures. etc.
[ NTFS ]
> > And it IMO does not make sense to fork its documented derivative out
> > of it (there was already one with unhappy end).
> Sorry I don't get what you mean. The old NTFS driver?
Sorry, I meant OS/2 HPFS/NTFS. The old story as the development of NT kernel
split between IBM and Microsoft at some point.
> > OK, it is a feature missing in current GPLed (incl. specification)
> > filesystems. It still makes more sense to me implementing the feature
> > to existing GPL filesystem instead of implementing the same feature to
> > NTFS with uncertain data structures.
> It's not uncertain, it's know for a while.
Filesystem must be the rock solid data storage structure. You must know the
meaning of each byte (*) for such reliable and interoperable filesystem.
NTFS is not documented in such level - even in the case of documented
compression structures there are missing points in the underlying generic NTFS
(*) You do not need to know the journalling metadata as long as you do not
support journalling and/or its recovery.
> > But we are talking about free software - do what you get paid for.
> I don't understand this. There are many reasons why people write open
> source software. Charity, bust ego, religion, fun, get paid, etc.
I did not see much real software written for a different purpose, YMMV.
Jan Kratochvil; http://www.jankratochvil.net/
More information about the wine-devel