[4826] in Release_7.7_team
Captive NTFS investigation
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Sep 11 10:03:48 2004
Date: Sat, 11 Sep 2004 10:03:41 -0400
Message-Id: <200409111403.i8BE3ft4006292@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
For a long time we've had a goal in our status report to investigate
Captive NTFS, which provides read-write access to an NTFS partition
using a wrapper around the Windows driver. I've concluded this
investigation, and decided that we probably don't want to try to
support it.
To support Captive, we would need to:
* Maintain a build of a small kernel module called lufs (as hacked
by the Captive guy) and keep it in sync with our kernels like we
do with the OpenAFS module. This would be the hardest part.
* Provide a build (possibly from external RPMs) of the user-space
ntfstools, which would be used to retrieve the Windows driver from
the NTFS partition.
* Provide a build (possibly from external RPMs) of the Captive
filesystem, which plugs into the lufs module.
* Do some scripting to tie all that together.
The work required would not be prohibitive, but I think the result
wouldn't be terribly satisfactory. A look at the relevant mailing
lists (http://www.jankratochvil.net/project/captive/#lists) suggests
that Captive is essentially unmaintained and receives little use. An
external review (http://www.gerdfleischer.de/wireless.php) suggests
that it performs poorly, particularly for large files.
One possible alternative would be to add an installer option to create
a modest VFAT partition (using mkdosfs) on NTFS systems. The VFAT
partition could then be used for document sharing. Or, we could
provide documentation (which wouldn't have to be Athena-specific) on
how to do this after the install using ntfsresize and mkdosfs.
(ntfsresize comes from the ntfsprogs RPM, which we don't ship but
which is easy to fetch. Red Hat won't touch it due to patent
concerns, as I understand it.)
