NTFS driver (was: ReactOS GPL vs. proprietary drivers)

Szakacsits Szabolcs szaka at mlf.linux.rulez.org
Wed Oct 22 03:32:31 CDT 2003


Hi,

On Tue, 21 Oct 2003, Jan Kratochvil wrote:
> On Tue, 21 Oct 2003 22:38:41 +0200, Szakacsits Szabolcs wrote:
> > 
> > I guess you mean reading? Anyway it depends on the driver quality. All
> > needs to be known for both read and write.
> 
> Not all information needs to be known for reading:

It depends on the driver quality. All needs to be known for both read and
write. In other words, one must know how the system works if he/she wants
_reliable_ reading, aka the data one read is trustable, not some bogus
value.

> > For exmaple the block allocation bitmap is used for filesystem consistency
> > check by ntfsresize.
> 
> Consistency is an addon useful feature although it is not required for
> successful reading.

Again, depends on quality. Specifically we are talking about NTFS, right?
Below is one of the many rebuttals from practice.

Partimage supports NTFS (experimental). It was implemented based on the
public NTFS documentation (it doesn't use the Linux-NTFS source base). For
example it doesn't check the filesystem consistency, just saves the blocks
marked in use in the block allocation bitmap ($Bitmap). Thus if the
filesystem is inconsistent (it do happen) then it will save the wrong
blocks: it might save what are unused and/or what's really fatal, it
doesn't save what are in use. Lost data.

> I spoke about OS/2 as an example of a split NTFS development. As I hope you
> agree it is not appropriate to split the development of NTFS filesystem in
> a way incompatible with Microsoft Windows NT.

If you have source you can make transparent extensions or just fork it 
and do whatever needed. Many open source project do this, it's one of the
strength of open source.

But I can't see such "danger". NTFS is pretty modular, plugin-like,
something what Reiser4 promises (but Reiser4 looks even cooler). MS just
plugged in what people need: compression, encryption, quota, link, WinFS
support, etc.
 
> It may be true but at the start of my Captive NTFS project coding
> there was no free implementation of read/write NTFS. 

No-one should expect NTFS kernel driver to be done in the near future
unless active development starts. But because people think NTFS is
undocumented (untrue) the chances are even smaller than it could be (and
those who could do it don't have the time for it).

> As I do not trust reverse engineered complex data structures for such
> sensitive content as the user data 

The reverse engineered, complex data structures were validated and in use
for years.

> I implemented the read/write NTFS in a way most reliable in my
> opinion.

Ok, I don't repeat here what I wrote on the other list, if one is
interested he/she can read it here:

  http://reactos.com:8080/archives/public/ros-kernel/2003-October/000294.html

Just a new one, robustness. I didn't test Captive NTFS but looking at the
system design it's a bit too complex. Error-prone. With a variable black
box (there are a lot of different ntfs.sys) in the middle. Sorry but I
wouldn't trust it for a minute. I sincerely hope I will be disproved by
millions of happy users.
 
> BTW there is still no non-Captive free implementation of read/write NTFS.

How long did it take to implement Captive NTFS? My estimation for a 
free (full GPL) r/w implementation is

  needed kernel knowledge:    3-9  months if one doesn't have it yet
  NTFS knowledge:             1-3  months if one doesn't have it yet
  finish r/w NTFS v2 driver:  2-6  months

	Szaka






More information about the wine-devel mailing list