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/00000...
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_conn...
...
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