On Tue, 2005-05-31 at 13:52 -0400, David Gonz?lez Romero wrote:
> Hi!! I have a CentOS 4.o install on some machine in my job. I need setting
> the system for read/write partition NTFS. I know the kernel-2.6.x this
> support is part of the kernel, but in CentOS this support is unaviable.
> How can aviable this support whit out recompiler kernel?? Some rpm packege
> for do that??
First off, read the Release Notes for the 2.6 RPM:
http://linux-ntfs.sourceforge.net/rpm/rel26.html
Secondly, if you are looking for a "safer" way to write NTFS filesystems
(especially for NT3/4), check out Captive:
http://www.jankratochvil.net/project/captive/
One thing I find that not only Linux people are unaware of, but even
MCSEs, is that modifying the meta-data (change in size, ACEs, etc...) of
a NTFS volume is _dangerous_unless_ it's done by the same NT
installation that created it. You normally shouldn't, even with the
same version (but different installation) of NT!
Long story short, various meta-data in the NTFS volume rely on meta-data
in the System Accounts Manager (SAM) part of the registry that created
the NTFS volume. These are system-specific, except in the case of using
domain objects. A domain (the controller portion) is essentially a
"network-wide" SAM (even in ADS, although Kerberos is used for
authentication, and the network-wide SAM is stored as part of the LDAP
tree). This is why domain controllers (even in ADS) don't have local
accounts -- and when you create a domain the first time, the local SAM
of that first PDC (or DC in ADS) becomes the new "domain" SAM.
If you touch part of a NTFS filesystem that relies on SAM meta-data that
is not a domain object (i.e., network-side SAM), then you can _trash_
the volume. This is not like UNIX where if you do not have a
passwd/group/etc... entry you just get the "Raw" UID/GID/etc... And
it's not just that Access Control Entries (ACEs) are lost. You can
touch sensitive areas of the NTFS volume. Part of the reason for this
"design" was to increase security, but in reality, it's really a "false
security" and a major bug in NTFS' design.
Prior to NT5 (2000 on-ward), Microsoft blindly allowed different NT
versions to mount NTFS volumes created by other . I've seen many people
trash NTFS volumes moving them between systems. I've also seen the case
where promoting a system with local SAMs to BDC or DC (ADS) status has
cause it to trash it's own NTFS volumes (although the ADS-DC logic does
more checking for this).
Starting with NT5, Microsoft does more sanity checking. E.g., install
NT5.1 (XP) on two different hard drives (basic disc) with NTFS and they
try to read each others. Disk Manager won't let you mount them from the
other install -- not even read-only (even Linux allows this!). This is
to protect you from trashing the other NTFS volume, because each NTFS
volume relies on local SAM meta-data. The exception would be a member
system/server trying to mount a DC's NTFS volume, the SAM is network-
wide so all entries should be domain objects (unless it was promoted to
a DC, and some old, local-only meta-data was around). That's why
PDC/BDC and DCs (ADS) can move volumes between servers.
NT5 also introduces "Dynamic Discs" -- Logical Disk Manager (LDM) Disk
Label (aka Partition Table format) -- another work around where basic
SAM information is stored in hidden areas (along with other information,
like geometry, volume sets/software RAID info, a journal of changes,
etc... that a "Basic Disc" -- legacy BIOS/DOS disk label, LDM disk
labels look like a single type 42h partition from DOS/NT3/4). Now it
doesn't guarantee you won't trash the meta-data (like ACEs) on files
when you mount a NTFS volume you didn't create with that NT5+
installation. But it _will_ prevent you from touching "sensitive" meta-
data like critical FAT and other meta-data areas of the NTFS volume
itself.
"Captive" under Linux is a combination of things. One is a ReactOS
(NTkernel/NT clone) stub with WINE and wrapper for various NT components
-- including a registry viewer/editor! That means you can far more
safely read the local registry of a foreign NT installation so you can
more safely read the NTFS volumes of that NT installation -- even on
pre-NT5 NT installations. Of course, it's far from perfect, and it is
user-space and _very_slow_. But it is a nice option to have.
In a nutshell, NTFS was _never_designed_ to be read by another NT
instance than the one that created it. This is an inherit limitation to
NTFS through version 5 (will NT6.0/Longhorn solve it? probably not).
The workarounds include the network-wide SAM (domain) and, as of NT5+,
the Dynamic Disc which can store key NTFS volume meta-data information
in hidden areas of the disk label (partition table). Hopefully the
NTFS-LDM project will reverse engineer this soon so we can have a
faster, kernel driver.
But until then, Captive is actually safer than it, and works for NT4.
But it's much, much slower.
--
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. ;->
