Create a Dual-Format Drive for Mac and Windows

It's just come to my attention that it's now fairly trivial to split a drive into two differently formatted partitions, one of which could be used for the Mac while the other could be used for Windows. This is not necessarily new, but there are a number of things that make it of particular interest to me. Before I detail the process of creating this dual-platform drive, I want to talk a bit about some of the reasons you might want to do this and some of the challenges I've faced over the years with regards to the issue of cross-platform drives.

Some History

In the very cross-platform lab where I used to work we were continually on the hunt for the best filesystem solution for users of multiple platforms when they were using external firewire or USB drives. That is, some folks wanted their drives to be accessible from both the Mac OS and Windows. On the surface this can seem like an easy problem to solve — Fat32 (or "MS-DOS" as it's called in Disk Utility) is readable and writable on both platforms. But it's not so cut and dry.

The biggest problem for me was video. See, I taught — and continue to teach — a video class in that very same department. We use Final Cut Pro as our editing software, for a variety of reasons, not the least of which is the fact that I prefer to work on the Mac. I require my students to have a firewire drive appropriate to showing in-progress video work in class. But Fat32 has a 4GB file size limit, and video captures can often exceed that limit. What happens when this limit is exceeded is interesting from a systems standpoint, but devastating from a user standpoint.

Video and Fat32

When capturing video in Final Cut Pro to a Fat32 volume, what happens is that the video file gets segmented. That is, the capture file gets written in 4GB chunks. Initially, Final Cut will see these chunks and understand what they are. But after saving the project and quitting the app Final Cut will no longer be able to locate the captured media because it's in multiple files with different names. The path to the media that FCP relies on is now, essentially, broken. This actually happened to a student of mine some time ago, and we were able to use the cat command to reconstruct the single movie file onto an HFS+ volume and then point FCP at the reconstructed file. Boy was that fun.

NTFS

We've often looked to the ever-popular NTFS file system as a possible future solution. It does not have such small file size limits, and it's readable on Mac and Windows. But the Mac has never been able to write to NTFS. So, in the past, our solution in the lab — our recommendation for users who really needed a dual-format drive with read/write capabilities on Mac and Windows — was to use the HFS+ filesystem on the drive and use MacDrive on Windows to read and write to that drive. Inelegant? Yes. But it mostly worked.

Mac and Windows Partitions

Another potentially attractive alternative to a single, dual-platform volume was the idea of splitting the drive into two partitions and dedicating each partition to a platform/filesystem. This way, even if all your Mac and Windows data wasn't all mushed together in one volume, you could at least keep it all on one device. This solution would likely work for the vast majority of users. Unfortunately, there was never a particularly straightforward way of doing this. Sure, it was doable. But it wasn't easy, and it wasn't something you could tell new students to do. In fact, it was likely to require admin access and command-line heroics, and so just wasn't a viable solution to anyone but the most die-hard user. Until now.

Without too much mucking around, it's now possible to create a dual-format external drive that contains a mac-formatted partition and a Windows-formatted one.

MacFUSE and NTFS for Mac OS X

The first step is the only really tricky part, and it's not even that tricky. If you have need for a dual-format drive, this should be pretty easy for you. You're going to need to install the MacFUSE and NTFS packages. In a nutshell, MacFUSE is an experimental set of tools for doing unsupported things with filesystems like SSH, FTP and, of course, NTFS on your Mac. And, experimental though it may be, I've been using it for quite a while and have not had any problems to speak of. Installing MacFUSE and the NTFS drivers will allow you to mount NTFS volumes with read-write access.

So, if NTFS can be mounted read-write on the Mac with MacFUSE, and it's obviously read-write on Windows, and it doesn't suffer from the file size limitations of Fat32, why not just use NTFS as your über-filesystem and format the whole drive with it? That's a great question, and I'm glad I asked it!

The thing about getting NTFS read-write access on a Mac with MaFUSE is that it's very much a hack. Yes, it works, but it has its problems. First and foremost among them is the fact that Final Cut Pro is really not a fan. In fact, FCP might just be the best barometer of a good cross-platform solution as it seems to be so picky about filesystems. So far, the only filesystem I've seen work consistently well with Final Cut is HFS+. No surprise there. And on NTFS it gets downright crazy. Files sometimes won't open. Sometimes they won't save. It's a scary mess, and I wouldn't trust my FCP data on NTFS for any amount of money.

But, what the MacFUSE NTFS package does get you is a relatively easy way to format your drive with separate Mac and Windows partitions, and this, at least in my tests seems to work just fine.

The easiest way to get everything you need is to go to the NTFS-3G for Mac OS X website and download the latest package. This package will install the most recent non-beta version of MacFUSE as well as the latest NTFS libraries, and contains everything you need. Once you've installed this bundle, you'll need to reboot your system.

Creating the Dual-Partition Drive

After the reboot you'll see a new filesystem option when you go to format drives in Disk Utility.

Moreover, that option will be available to individual partitions of drives that are otherwise formatted. And that's what's new (to me) and what allows the magic to happen. Here's how you do it.

1. First, if you have any data on the drive that you need to preserve, back it up. This process WILL ERASE YOUR HARD DRIVE.
2. Next, select the drive you want to dual-format and choose the Partition tab.
3. Select a Volume Scheme. I'm just doing the simplest, two-partition scheme, with one Mac and one Windows partition, but you can certainly get more Byzantine with it if you'd like.

   

4. Set the Format for the partition you want to use on the Mac to "Mac OS Extended (Journaled)," give it a name and a size.

   

5. Set the Format for the partition you want to use on Windows to "Windows NT Filesystem (NTFS-3G)," give it a name and size.

   

6. Under the Options... set the partition scheme to "Master Boot Record." This is needed for Windows to see your drive.

   

7. Finally, hit the Apply button. You'll be warned that everything is about to be deleted. Click through, and after a few seconds you will have completed the formatting process and your dual-format drive will be ready for use on Mac and Windows.

Caveats

As I said, so far this has been working really well for my class. You may still want to file it under "experimental" for the time being, at least until you're sure it's working safely. But I'm confident enough in this method to recommend it to my video students who also need some external Windows drive love.

It's also important to keep in mind here that I am not endorsing using the NTFS partition for Mac data of any kind. Doing so is surely unsupported by Apple, and by all reports is fraught with problems.

The other thing to keep in mind is that, unlike with a GUID partition table, you will not be able to resize or split partitions without completely erasing the drive.

Conclusion

Lastly, I realize that this process is hardly new, nor am I the first to discover it. It was pointed out to me by one of my video students, and I have a feeling the new admins at my old job have been using it for some time. But it's new to me. This is the first I've heard of this and it's exciting to me from an academic standpoint, in the context of my old job, in the context of my class, as a new option I can offer to whomever might need it, and as a symbol of progress — however small or kludgy — towards cross-platform filesystem solutions. This is just another of the very cool advances made possible by the existence of the MacFUSE (and the original Linux FUSE) effort. It's very cool to see this sort of thing coming to fruition at last!

Another intriguing extension of the MacFUSE project — and one that I've used a bit myself — is MacFusion, which allows for mounting of data over network protocols such as FTP and SSH. I'm sure there are tons of others. I highly recommend folks — particularly SysAdmins — check out and familiarize themselves with MacFUSE in general, as well. As much as has been done since the last time I looked at it, there is still a ton of future potential in the project, and I see it increasingly becoming a part of the admin's toolbox.

Native App Superiority

I was recently reading an article on the Tao of Mac that said, among other things:

"I’ve long preferred to use iPhone Twitter and Facebook clients over desktop ones..."

It's true, there are a handful of iPhone applications that are actually better than the original apps they replace — Facebook, for sure, and my recent fave, the Zipcar app among them. Of course the original ones — the "Desktop ones" referred to in the article — are actually web applications.

The fact is that, despite the push towards — and what many believe is the inevitability of — the web as the primary source of applications, native apps are still vastly superior in almost every instance. This is why Apple had to finally give developers —  and consumers, of course — the App Store. Web apps just weren't cutting it on the iPhone. And while they do somewhat better inside a full-sized browser on a full-powered computer, I still think web apps have a long way to go — a very long way — before they'll ever rival the experience of native apps. Platforms like the iPhone and continued interest in things like Site Specific Browsers offer very convincing evidence that native apps will continue to thrive for a long time to come. To be honest, I have my doubts that web apps will ever completely replace native ones.

I should also point out the probably obvious fact that there are certain apps that will always be best on a mobile platform because they just happen to be particularly well-suited to mobility. The Zipcar iPhone app is a perfect example. It's an app for finding, renting and controlling cars, for Chrissake. Where better to have an app about travel than on a mobile device? In fact, having the Zipcar app on an iPhone gives it certain powers the web app will likely never be able to match. But I'd venture to say that there are very few, if any, application experiences that are better in a web browser than they would be in a dedicated, native app.

No doubt about it, web apps are supremely useful, especially for certain tasks. But that's like saying the web is useful. The ironic fact that many of us prefer surfing Facebook on our iPhones to using the original web app version on a full-sized computer should give you an idea of just how hard it will be and how long it will take to supplant native apps with web apps.

Snow Leopard Scanner Application

It's been widely reported that the Image Capture app in Snow Leopard can now see and scan from many common scanners. This is a huge boon to those of us who are sick and tired of crappy scanner drivers and software. Image Capture is quite a capable scanner app, and fairly Mac-like.

But there's another, more direct way to access your scanner without opening Image Capture.

Just like with printers, adding a scanner (either via Image Capture or directly in your Print & Fax preference pane) will create a scanner application in ~/Library/Printers. This can be dragged directly to your Dock for quick, easy scanner access.

Or, if you open the scanner directly from the Print & Fax prefs, it will appear in the Dock where you can simply right-click it and choose to "Keep in Dock" from the options.

All-in-all native scanning is an extremely handy feature and seems to work well in my tests. Keeping my scanner in my Dock just makes it that much easier to use.

Snow Leopard Server-Related Changes

That title should give you a hint just how much my responsibilities have changed since I took my new job. Yes, I still run a Mac OS X Server, but I no longer get bi-yearly hardware updates. So my server is running a PPC, as is my workstation. So no Snow Leopard Server for me, at least not for a while.

I have noticed (as have many others) a few changes to how Snow Leopard handles certain server-related tasks, and I thought I'd just jot them down for the record — mine as much as yours.

Directory Utility

The first, and possibly weirdest, change is that Directory Utility is no longer a readily available application. It now lives in the very unintuitive /System/Library/Core Services, which tells me that Apple would rather us not use it unless absolutely necessary, which, generally speaking, it should not be, at least not for binding to Open Directory servers. Much of its functionality has moved to other applications and parts of the OS.

OD Server Binding

Curiously, OD binding now happens in the Login Options section of the Accounts preference pane. Even more curiously, you can open the Directory Utility from here as well:

NFS Mounts

Directory Utility used to have a pane for configuring NFS automounts. That pane has been moved to the arguably more logical Disk Utility application, where you access it under File->NFS Mounts, but it looks pretty much the same as it did before:

Root User

Since 10.5 the root user has also been activated via Directory Utility. I haven't found a new way to do this. It looks like if that's your bag you'll need to either find a way to open Directory Utility, or use the command-line. 'Course, if you know what root is, you shouldn't find either of these things terribly difficult. Especially since I just told you two ways to do the first thing.

Directory

There used to be an app called Directory in the Utilities folder, but it too is gone. I'm assuming some of its functionality has been added to Address Book, which now has its very own Accounts preference pane:

And I've read that some of its functionality has been moved to the iCal Server Utility app now included with the 10.6 Server Admin Tools:

I've also read that there is some functionality that is completely gone now.

MCX Cache

A fellow SysAdmin has posted his own groovy list of Snow Leopard changes as well. My favorite:

"New command, mcxrefresh, used for refreshing managed preferences on clients"

Hallelujah! I've bitched frequently about Mac OS X Server's overly aggressive cache. Having a way to clear it makes all the difference.

Conclusion

So we have a bit of a shuffling around here, but overall it looks to me like Apple is trying to keep simplifying the OD binding and setup process in Snow Leopard, as they have done with each iteration of Mac OS X. The most obvious features are in obvious places, whereas the more obscure features have been moved to more obscure locations. Most of these changes make sense, too, though dedicated apps for OD setup make sense on some level too. Must everything be another preference pane? In any case, it's just good to know that all the same stuff is there, it's just been moved around a bit.

On a personal note, it's a bit of a bummer to not get to play with Snow Leopard Server. I may never get the chance, actually. It could be long gone by the time we get new hardware, and we just don't rely on Mac OS X Server like we did at my old job. Ah well life goes on.

If anyone has any Snow Leopard Server stories to share, I'd love to hear them in the comments. As far as reportage goes, though, I'm gonna have to sit this one out.

Installing Firefox On the Mac

Alexander Limi, one of the developers of the fine — and my favorite — browser, Firefox, recently issued a challenge that has been heard by many: how to make application installation more sensible for the less technically advanced. What followed — and, to some extent preceded — was an explosion of discussion on the matter.

It really is somewhat amazing that the preferred method for installing a good deal of Mac software — the so-called "Manual Install" — is one that's liable to be confounding to so many users, particularly given that Apple has gone to such great lengths to simplify software installation. And I agree with much of what I've read on at least one point: The problem is the DMG.

"They drag the application to their dock directly.

This creates a link to the file inside the disk image, which means that every time they try starting Firefox, the disk image is unpacked and mounted, and starting of Firefox becomes very slow, which makes it a bad experience."

It's true; I've seen very computer-savvy users constantly launch Firefox directly from a Dock icon that's linked to the item on the disk image. And there are certainly many users to whom you'll never be able to explain exactly what a disk image is, how it works or why it exists. Frankly, as useful as it is to geeks like you and me, it's kind of a crazy concept for anyone who doesn't care about these sorts of things. And I'm of a mind that most users don't and shouldn't.

That said, our options are limited when it comes to installing software. As Limi points out, most apps these days are actually folders (another conceit most users aren't and shouldn't be aware of), and so they must be installed from some sort of container, particularly if they're coming from the Internet. This can be either a ZIP file or, as is generally the way on the Mac, a DMG. Typically, Apple uses a DMG that contains an Installer package for distributing their own software, probably because their stuff is usually not simple drag-and-drop stuff. They've also created a special "internet-enabled" flag for DMGs that, when applied, will be recognized by Safari, which will proceed to open such DMGs and run any installers contained therein. This, at least, gives us a way to accomplish some of Limi's stated goals for the Firefox installer:

1. Start the Firefox download.
2. When the download is complete, the disk image will mount automatically (if they were using Safari), and the Firefox installer runs.
3. The install procedure continues similar to how it happens on Windows.
4. As the last step of the process, the installer lets you set Firefox as the default browser, and start the application immediately. We have seen users forget that they just installed Firefox if you don’t let them start it at the end of the process, and make that the default choice.

Having some experience with Mac OS X package creation, I decided to see if I could quickly whip something up that met these goals. I believe I have been successful. Here's the installation procedure I've designed:

1. The user downloads the Firefox Installer from Safari.

   

2. Safari Opens the DMG and runs the Installer.

   

3. The Installer uses a standard method by default, which requires a minimum of clicks, and installs Firefox in the default location, /Applications.

   

4. Upon pressing "Install," the Installer requests authentication.

   

5. Before proceeding, the Installer's preflight routine quits Firefox if it is already running (this is not necessary, we do it as a precaution).

   

6. The Installer then proceeds with the installation of the app.

   

7. When it has finished it will open the containing folder and highlight Firefox.

   

8. And then it will launch the app. If this is the first launch, Firefox will ask the user if she wants to set Firefox as the default.

   

This is the basic install procedure, but some more advanced users will, of course, want to customize the install location of the app. To that end, the installer I've built also contains a "Customize" option.

Clicking this will allow the user to customize the install location of the app by selecting "Other" from the Location pull-down.

And then choosing the location from the resulting menu.

I believe this method offers the best of all possible worlds given the current state of off-the-shelf installation options for Mac OS X. It offers some level of customization for advanced users, while still offering a guided experience for less Mac- or tech-savvy users. And I believe it fulfills most or all of Limi's stated goals for a Firefox installer. There are even numerous things we can do to further customize this guided experience — things like adding graphics and explanatory text, or running additional pre- and post-flight scripts to perform certain behaviors.

And this will work great for most folks who use Safari as well. But for anything beyond this particular scenario — i.e., anyone trying to install apps from browsers other than Safari, which would be anyone who uses the above method, i.e. Firefox users as well as users of any other browsers — we still have a problem. That problem is DMG behavior. The DMG, despite being immensely useful and a perfectly good application and installer container, once downloaded, is easily forgotten. It's behavior and purpose are arcane to most users. They don't know what to do with it and are confused by its presence. And it has nothing to do with anything normal users think of as "Software Installation."

Some developers have rolled their own solutions to some of these problems. But I think the answer really needs to come from Apple in the form of a unified, internet-savvy Installer format. Something that knows where it comes from and what it's supposed to do, and once downloaded, just does it. Something that developers can all use for any kind of installation, even so-called "simple drag-and-drop." Something that just works, dare I say, at least as well as it does on Windows. Preferably better.

Given the level of abstraction of so many concepts in modern operating systems — applications are folders, disk images are files that can represent volumes, Soylent Green is People — I think drag-and-drop installers are bound to be confusing to many users. The guided experience, while a bit of a bummer for very advanced users, should be the preferred method. And I think the best candidate for improving upon that method is ultimately Apple.

One thing that would help the situation immensely, though, is if browser developers made their apps internet-enabled-DMG-aware, like Safari is. This goes a long way towards mitigating the confusion wrought by the ever-confusing, yet — at least at this point in the game — fairly necessary DMG.