Christopher Hotchkiss (christopher.hotchkiss@gmail.com) wrote:
> the only ntfs write support that exists is very experimental and can
> not change the size of the file.
The issue with "safely" writing to NTFS is not a Linux one, but a NTFS
one. Sadly, not many MCSEs know this, and I've seen them toast their
filesystems before after they've moved disks and then moved them back.
SHORT ANSWER: Always use Captive in Linux (if available)
LONG ANSWER: (for completeness, ignore if you don't like verbage ;-)
To start, NTFS was _never_ designed to be written to by a system that
did not create the filesystem. Because NTFS filesystems store Security
Identifiers and other information from the System Accounts (SAM)
database in the registry, you should _never_ write to a NTFS filesystem
that does not have an _exact_ match of the SAM-SID. And that includes
another NT installation.
The native "Microsoft" approaches to dealing with this are:
1. Use a "network SAM-SID" -- this is a "Windows Domain," be it old
CIFS/NT4 or newer ADS-2000/2003. The "controller"
(authentication/authorization) functionality of a "Windows Domain" is
basically a mechanism by which a network-wide SAM-SID is created. As
long as all the files on a NTFS filesystem have "Windows Domain" SAM-SID
in their meta-data, such as on a PDC/SDC or ADS-DC, it is safe to move
the NTFS filesystem. Unfortunately, it's not good with a local SAM-SID
could have written files to a NTFS filesystem (like on a workstation,
standalone server or Domain Member).
2. Partially to solve the issue of #1 (among other issues with NTFS and
storage), Microsoft introduced the "dynamic disk" (aka Logical Disk
Manager, LDM, disk label) in NT5+ (2000, XP, 2003). The LDM disk label
(partition table) solves a lot of issues with the older "basic disk"
(aka PCBIOS/DOS disk label), including storing SIDs in hidden areas of
the disk label. That way, other NT5+ systems can read these SIDs so
they can safely modify NTFS filesystem meta-data -- even if the other
system's local SAM-SID registry is not on the disk (which is the case of
portable storage). It doesn't necessarily mean they will understand how
the SIDs map to accounts, authorizations, etc..., but they can at least
modify the NTFS filesystem safely (loss of meta-data still may occur,
but the filesystem won't be "dropped" into an unrecoverable state).
Under Linux, the support for reading the SID entries via LDM support is
still under development. And any such development would only help NT5+
when "dynamic disks" are used. Fortunately, there is a cooler
alternative that works for "basic disks" as well as NT4. That is
Captive for Linux. This allows not only safe writing of meta-data, but
even reading of the meta-data that SID storage in hidden LDM areas
cannot.
Captive is a kernel driver that ties into a set of user-space software.
This software can _read_ the registry of a NT4/5 system, including the
all-important SAM-SIDs. There is really no equivalent in the Windows
world (although some 3rd parties claim to offer such). Of course there
are IP and legal issues, so Red Hat won't allow its inclusion in
Fedora(TM) Core or any repositories (like Fedora(TM) Extras) that
utilize Red Hat resources.
Additional Note: Now there are tools to move and resize NTFS
filesystems. You don't need to be able to read and modify SIDs and
other meta-data when you do this. In fact, the Linux NTFS-LDM project
has tools to _safely_ move and resize NTFS partitions, both on "basic
disks" (which Microsoft claims is impossible in NT5+) and "dynamic
disks." The key here is that the meta-data is _not_ changed, so the
SIDs and other information is not changed.
The danger is when you do change this meta-data. Hence why mounting a
NTFS filesystem as writable is a dangerous thing if it wasn't created
with that specific instance of NT -- _regardless_ of OS (even native
NT).
> Me - I just use a fat32 partition and use that to share files between
> Linux and Windows.
Unfortunately FAT32 support above LBA26 (512*2^26 = 33GB, 32GiB) is
problematic. Hence why even NT5 (2000, XP, 2003) doesn't let you
install on a larger FAT32 filesystem than 32GiB. Above LBA28 (512*2^28
= 137GB, 128GiB) is a major issue for FAT32 -- especially if you use a
"basic disk" (DOS disk label).
I could go into this further but basically now that disks are bigger
than 32GiB and 128GiB, Linux distros need to support the LDM Disk Label
for just purposes of reading the assumed disk geometry by NT5+. Long
story short, under old "basic disk" with pre-32/128GiB disks, it was
easy to "guess" what geometry DOS/NT used. That now changes with larger
disks and the proliferation of NT5+ (2000, XP, 2003), which can use
geometry completely different than the BIOS or what can be assumed for
LBA (logical block addressing).
Especially on "buggy BIOSes" that lack full Extended Int13h services
support *COUGH*IBM*COUGH*. This has caused a lot of issues for distros
using kernel 2.6 and GRUB and the current attitude is not to try to
"assume" what the geometry is (which kernel 2.4 did). Frankly, I don't
blame the kernel developers from re-implementing the "old way" --
especially now that disks exceed 32/128GiB.
Long story short, the "dynamic disk" (LDM disk label) stores the
exacted, assumed disk geometry by NT5+. The stock Linux kernel supports
LDM disk labels (LDM is part of the NTFS project, but 100% separate from
the filesystem read/write driver portion), including reading this and
other details. The only thing missing is GRUB support for LDM and the
user-space/installer tools. Everytime I suggest this, I get shot down,
but it would solve all sorts of issues -- and the Linux kernel has
support for it _today_ (and LDM disks are bootable with LILO too, GRUB
just lacks a LDM driver at this time).
Don't be surprised with LDM is required for new NT6/Longhorn
installations. It's not an anti-Linux thing, but LDM solves a lot of
issues with the old, legacy PCBIOS/DOS disk label -- from geometry to
NTFS SAM-SID issues. The good news is that LDM doesn't change, it's
designed specifically as a "future standard" -- even on other
architectures. E.g., LDM is not only used in the legacy 16-bit PC BIOS
(LDM = type 42h primary), but also to the IA-64/Itanium firmware with
its GPT disk label (LDM inside of GPT).
For Linux servers, the obvious choice is to use Red Hat (formerly
Sistina) LVM/LVM2 disk labels. But for dual-booting workstations, the
distros really need to adopt support for LDM disk labels IMHO -- if only
for solving the post-LBA26/28 geometry assumptions/conflicts.
-- 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:24:33 EDT