Every so often I run across a situation where an admin has a file system on a server that he wants to convert from...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
a Linux-compatible file system (typically ext2/3/4) to a Windows-compatible file system (NTFS, or even FAT32). The catch: He wants to perform the conversion in-place—something akin to the Windows ability to convert a FAT32 volume to NTFS via the convert command.
Sadly, such a conversion is just about impossible, and I suspect it won’t be possible anytime in the future either. There are also plenty of reasons why this feature is not a good idea in the first place, and it's becoming less and less necessary, anyway. Here’s why.
First off, in-place conversion of disk formats is inherently dangerous. When you’re working on the only available copy of a given file system, that’s a risky action. You’re trusting the program to manipulate the entire volume at once, with little margin for error. If something goes wrong during the conversion, your only copy of that data is ruined. Plus, if that data has any value to you at all, it’s worth backing up—and if you make a backup, you’re better off working from that backup copy in some form than the original in any form. That’s your first option right there: instead of messing with the volume as-is, back it up in some form—whether by a backup utility, a disk-imaging program or a simple archiving tool—and use the backup to recreate the data somewhere else in the needed file system.
Second, some of the features of each file system do not map precisely to the other. One pretty obvious example is the way Linux file systems like ext3 and ext4 (and Unix file systems generally) have features that cannot be replicated in NTFS at all. Two examples come to mind. The first is the way Linux file systems are case-sensitive: you can, for instance, have two files named RASTER and raster in the same directory. NTFS would only allow one file with that name, no matter what case was used for it. Another example is the way names in Linux file systems can contain characters that would not be permitted in NTFS, such as slashes or the pipe character (|). If you attempted to convert an ext3/4 file system to NTFS, file names would have to be modified to ensure compatibility—which might in turn break other things.
Third, there are almost no scenarios left where you have to perform an in-place modification. Storage has become exponentially cheaper and more flexible in the last decade, which means it’s cheaper (and easier, and safer) to hook up a second drive and mirror the contents of the drive to it rather than attempt in-place conversions. In almost every scenario I’ve been presented with, the need to upgrade something in-place has been more about a failure of imagination or creativity on the part of the admin than any actual technical restrictions on the part of the system in question. If you do find yourself in a situation where you have to migrate data, there are plenty of options that don’t involve in-place manipulation of partitions.
1. Back up the data and restore it elsewhere.
As indicated above, this approach is the simplest, most widely supported and least complicated. All you need is a target device of some kind that can be read by the target system. Most breeds of Linux now come with some form of read/write NTFS compatibility built in, or if all else fails you can write to a FAT32 volume (which is broadly supported by Linux, too) or a network share. Note that if you’re using FAT32 as the target, any files written to that volume—whether they are simply copies of the files on the source drive or backup archives—need to be less than 4 GB in size. FAT32 cannot handle files bigger than 4 GB, so making a monolithic backup file on such a volume is out of the question; you’ll need to break it into chunks if possible.
2. Add Linux file system compatibility to Windows and move the files in Windows.
Windows does not by itself have native support for ext3/4 or other Linux file systems, but it can be added after the fact. The Ext2Fsd project, for instance, allows you to mount and read ext2 through ext4 (although ext4 is read-only at this point), although it doesn’t support LVM or Linux RAID volumes. Other, similar projects also exist—EXT2IFS, and fs-driver.org—but Ext2Fsd seems to be the most regularly updated of the bunch and has features the others don’t.
3. Add Windows file system compatibility to Linux and move the files in Linux.
While it’s also possible to do this—most editions of Linux now have NTFS support as a common feature—you may be better off using Windows as per #2 above for a couple of reasons. One is file permissions: if you’re using Windows to retrieve the files and place them on an NTFS partition, you won’t have to do any additional checking to make sure user permissions and other NTFS meta-attributes are being set and maintained correctly.
Follow SearchWindowsServer on Twitter @WindowsTT.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.