> I _never_ dual-boot NT/Linux where any FAT32/NTFS volume > crosses 33.GB (32GiB) HUH? FAT32 problem??? My system has two 120GB disks and a 160 GB disk. The 120s have a 1GB DOS, a 24+GB NTFS, and a 84+GB FAT32 partition. I keep (almost) all of my data in the FAT32 partition. The first 120 is (fairly) regularly cloned onto the second. Since I upgraded my BIOS, I have never had any trouble accessing anything in either of the big FAT32 partitions from either the XP installation or any one of the various Linux installations (CentOS, WBEL, SUSE, Fedora core 3, or Yoper) on the 160GB disk. At various times I have installed the NTFS code in a Linux installation, but when the NTFS crew's website says "read, but don't write" I believed them. -mj- Bryan J. Smith wrote: > 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 > >