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