On Tue, 2004-11-16 at 14:08, Steven Buehler wrote:
> I got Captive NTFS working in Fedora Core 3, or so I thought. It writes to
> the NTFS partition, but when I switched over to Windows to read it, the file
> was not usable.
Did you umount the NTFS filesystem before rebooting? Apparently there
is no guarantee that the kernel will automatically umount "user"
filesystem drivers safely at reboot, and this includes the current
Captive approach, so you should automatically.
Also note there is also _no_ guarantee that a file will exist with
proper meta-data even if you write it from another, native NT5+ (2000,
XP, 2003) system on a LDM disk label ("dynamic disk"). This is a
continued issue that plagues NTFS' inherent design and external SAM-SID
requirement for meta-data.
So in a nutshell, Captive and the NT5/LDM only guarantee you won't toast
the NTFS filesystem or write to it in a way that it would be
inconsistent. Hence why writing to NTFS except with the native
installation that created it continues to be a "Bad Idea(TM)."
> The guy that made Captive NTFS is no longer actively developing the product,
> claiming that the product does what it was designed to and needs no
> more tweaking.
Or the fact that there could be legal issues.
> I did find a Windows driver to read ext3 systems and the laptop is fast
> enough that rebooting to the other OS isn't too much of a pain, but it would
> be nice to be able to read and write to both systems.
Microsoft designed the NTFS filesystem with a lot of "false security"
features, one being the requirement of external meta-data from another
source -- namely the SIDs in the SAM of the registry. The result is
that you _can_ read it (bypassing the "false security" design), but not
safely write to it -- not even with native NT itself. The history has
now become a series of workarounds by Microsoft (as I detailed before).
No other filesystem has such external meta-data requirements, hence why
Ext3 and other filesystems can be safely mounted by other operating
systems.
BTW, understand these SAM-SID tie-ins have nothing to do with NTFS5's
Encrypted Filesystem (EFS), although EFS does take advantage of the
SAM-SID references in NTFS5. In the default EFS approach, if you know
the administrator password you can access _all_ EFS files. You must use
X.509 certs to prevent this -- which means we're back to manual
processes you can do with non-NTFS filesystems as well. ;->
[ If you notice a trend here, I spend a lot of my consulting life
smashing marketing BS and explaining technical reality, often while
wearing my MCSE shirt for overall effectiveness. ]
What to do I don't know. At this point, networking protocols are safe
option 1. When that is not an option, FAT32 is preferred. But if the
volume is larger than LBA26/32GiB or LBA28/128GiB, then something like
UDF is ideal. Of course, Windows doesn't come with a free UDF writer
the last time I checked (or does NT5.1 aka XP/2003?).
-- Bryan J. Smith b.j.smith@ieee.org -------------------------------------------------------------------- Subtotal Cost of Ownership (SCO) for Windows being less than Linux Total Cost of Ownership (TCO) assumes experts for the former, costly retraining for the latter, omitted "software assurance" costs in compatible desktop OS/apps for the former, no free/legacy reuse for latter, and no basic security, patch or downtime comparison at all.----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:26:51 EDT