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

[Jan Kratochvil]

Hi,

On Wed, 22 Oct 2003 10:32:31 +0200, Szakacsits Szabolcs wrote:
> On Tue, 21 Oct 2003, Jan Kratochvil wrote:
...
> 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.

The project design separated all the bug-prone code to an inner isolated box
(sandbox) while leaving only fully open source thin UNIX layer around:
	http://www.jankratochvil.net/project/captive/doc/Details.html.pl#sandbox

(The diagram does not appropriately show the real amount of codebase as 95% of
the project effort is implemented in the center 'ntoskrnl.exe' box.)

As the disk data blocks are flushed only after the successful unmount operation
there is a little chance the data structures would be corrupted. Any Captive
bugs (*) during the project development cause sanity crash where no disk blocks
get modified. If any crash occurs you may loose your last-minute written files
although the disk remains intact. Such possible crash is logged to
/var/log/messages with all the filenames involved.

(*) There remains a sensitive part of undocumented Cache Manager Windows NT
    subsystem as its incompatible emulation directly affects the disk data
    blocks. Behaviour of the original Cache Manager was thoroughly traced
    by my written TraceFS.sys and its output was afterwards sanity checked by
    my special Perl error-checking Cache Manager implementation to fully
    understand it for the successfuly emulation:
	http://www.jankratochvil.net/project/captive/doc/CacheManager.html.pl
	http://www.jankratochvil.net/pipermail/captive-devel-list/2003-October/000007.html

To ensure the maximum level safety it is also recommended to use the Microsoft
Checked Build (assert()s enabled) release of ntfs.sys/ntoskrnl.exe although its
main benefits were seen during the Captive development. More discussion about
Captive NTFS paranoia error prevention can be found at:
	http://www.jankratochvil.net/project/captive/doc/Details.html.pl#paranoia
	http://www.jankratochvil.net/project/captive/doc/Details.html.pl#parent_connector

...
> 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

It does not make sense to me compare LinuxNTFS and Captive NTFS as there is
just a completely a different level of reliability (no replies, please :-) ).
Captive NTFS primary goal was to reach _reliable_ NTFS and according to the
betatesting phase of the project it was successfuly reached.

Also any further versions of NTFS filesystem require no or little effort for
Captive NTFS while it may - or may not - require another major reverse
engineering effort for the LinuxNTFS approach.


My implementation of the part of Microsoft Windows Kernel API required for
ntfs.sys (own 116 funcs, orig/modified ReactOS funcs 113, 83 of ntoskrnl.exe)
took 14 months without any Microsoft Windows experience before. Time includes
the final deployment preparation such as the packaging and installer.  As the
whole project is GPLed and no profit was made out of it it could not be my
primary task.

BTW I expected less effort for my project initially. 14 months above is the
real final duration while any work estimations are always very optimistic.
Any NTFS implementation is about debugging where is no real estimation possible.



Lace

-- 
Jan Kratochvil; http://www.jankratochvil.net/