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.