On Tue, 2005-05-31 at 19:39 -0600, Collins Richey wrote:
> Unless you like running head on against traffic, don't even think
> about writing NTFS files from Linux. Never let anything but Windows do
> the writes.
Again, are you sure about that "Never let anything but Windows do the
writes" (given my prior commentary)? @-ppp
Understand I'm not trying to "single you out." There's just a huge pool
of MCSEs and other Windows administrators who have open skulls due to my
"encounters" with them after they've roasted NTFS volumes because they
either flopped disks around non-DCs, or promoted a system with lots of
localized SAM meta-data on its NTFS volume to a DC.
In reality, there are two _really_good_ things about Linux when it comes
to NTFS support:
1) You have a read-only driver option
2) Captive works fairly well (although slow) for what it was intended
With regards to #1, I can "safely" mount a NTFS volume read-only in
Linux. In NT -- especially NT4.0 with a NTFSv4 -- it can get toasted
because there's really no way to designate read-only. Furthermore,
while NT5.1/XP is good about not allowing a NTFS volume created by
another NT5.1/XP instance on a Basic Disc (legacy BIOS/DOS Disk Label
aka Partition Table) to be mounted, that's not very helpful if you just
want to read and get stuff off of it. ;->
Regarding #2, Captive allows fairly safe NTFSv4 writing -- something
that NT4 can't do. And depending on how well Captive is running, it can
even read the local SAM of an NT installation, providing better
preservation of ACEs meta-data when you mount and modify than even NT5
on a Dynamic Disc.
The problem is NTFS itself, even on NT, not Linux at all.
<Tangent>
NTFS has some serious issues with even NT -- and the work-arounds since
the original NT3.1 are half-backed. This was supposed to have been
addressed in NT4.0 "Cario" -- and then by the spin-off and promised
"CairoFS Technology" once it was separated from NT4.0's release to make
the date. Now we're seeing it yet again with NT6.0 "Longhorn" now
renamed "WinFS Technology" (as part of other "WinFX Technologies" --
like some parts of the Indigo ".NET Services Sandbox" and Avalon 2.0
with MacOS X-like QuartzExtreme functionality have now been pushed out
of NT6.0 "Longhorn").
</Tagent>
> On my dual boot systems, I alwas include a small FAT32 partition for
> transfer of files between the two. Both OS can write safely to FAT32,
> and then you can transfer the files wherever needed.
But an additional problem can be geometry. NT4SP4 does not specify a
standard geometry approach above 1024/63/255 Cylinder/Sectors/Heads =
8.4GB (8GiB) on the legacy BIOS/DOS Disk Label (i.e., the "Basic Disc"
partition table format. I.e., it's not guaranteed to safe to dual-boot
a system where FAT32/NTFS volumes are beyond the first 8.4GB of the
disk.
Worse yet, NT5+ (2000+) doesn't either, as Microsoft assumes you would
use a Logical Disk Manager (LDM) Disk Label (i.e., "Dynamic Disk"). Now
using LDM solves these problems -- because not only can other NT5+
installations read the exact geometry assumed by another NT+
installation, but so can the Linux kernel (as of early 2.4.x, thanx to
the Linux NTFS-LDM project).
Now until more recent NT5.1 service packs -- e.g., SP2 for XP, among
many pre/post-hotfixes, I never ran into this under 137GB (128GiB). But
as of SP2 as well as different hot-fixes, some even conflicting (just
ask NetCell about those details, their ATA RAID cards have run into
them ;-), I _never_ dual-boot NT/Linux where any FAT32/NTFS volume
crosses 33.GB (32GiB).
Unfortunately, the user-space tools for partitioning (Parted) and
booting (GRUB) aren't there to boot Linux on a LDM Disk Label. Sigh, so
catch-22 on using LDM Disk Labels as standard. Hopefully LDM Disk Label
support will be more commonplace in the near future. I'm fairly certain
NT6.0 "Longhorn" will require LDM Disk Labels and drop the legacy
BIOS/DOS Disk Label altogether (except for the fact that programs
assuming such will see the former as the latter with a single, type 42h
partition).
> But, in any case, on CentOS you need the unsupported kernel, because
> RedHat couldn't be bothered to include NTFS in the standard kernel.
Wow! I actually responded above _before_ even reading this. I hope
everyone, as well as yourself, can understand the "benefit" of
understanding why something like this isn't enabled by Red Hat.
Which goes back to my whole thing of "explaining why" instead of making
such statements like "couldn't be bothered."
Lack of write support actually has more to do with _real_ technical
issues than anything else. Although I'm sure the reason why at least a
read-only driver is not included as standard is probably legal-related.
Barring the legal issues, I _do_ think the read-only driver should be
included as standard.
> Just my $.02
Well, I try to offer the knowledge I have. I'll leave it to others to
either verify I am indeed correct, or assume that I pull it out of my
rectum. Apparently my rectum seems to be a popular assumption. @-ppp
--
Bryan J. Smith b.j.smith@xxxxxxxx
---------------------------------------------------------------------
It is mathematically impossible for someone who makes more than you
to be anything but richer than you. Any tax rate that penalizes them
will also penalize you similarly (to those below you, and then below
them). Linear algebra, let alone differential calculus or even ele-
mentary concepts of limits, is mutually exclusive with US journalism.
So forget even attempting to explain how tax cuts work. ;->
