Mobile Me vs. Dropbox

So I've been using Dropbox for quite some time now and I've been extremely pleased with it. It keeps my stuff in sync, and I don't have to even think about it. And that's what you want from a service like Dropbox: seamlessness; ease-of-use; freedom from worry.

I'm using the free version, so I only get 2GB of storage. This has been plenty for me so far, but I often wonder about what I should do if I ever hit that limit.

I've also been using Mobile Me for just over a year. I mainly got it to tinker with, as well as for the off chance that I should someday lose my iPhone. In addition to the various things you can do with MobileMe — none of which I ever actually do, it turns out — you get 10GB of disk space on your WebDav-connected iDisk, and this can be synced to any computer you sign on to much like your Dropbox account is synced. So I've been tempted to replace Dropbox with MobileMe, since I'm paying for it anyway. Before going ahead with a dedicated switch, though, I thought I'd give it a try for a while first. See how it stacks up against Dropbox.

It turns out — and this will probably come as no surprise to current MobileMe subscribers — that the iDisk functionality is problematic for a number of reasons.

First of all, MobileMe occasionally tells me that there is a sync conflict, despite the fact that I've told it to always keep the latest version of a file. This is something you never see with Dropbox. Ever. I'm not sure how the two services differ in terms of their syncing algorithms, but Dropbox definitely has the edge.

But perhaps more disturbing is the fact that MobileMe — an Apple-hosted service, mind you — doesn't seem to be able to retain Mac-specific data on certain files synced to iDisk. Case in point: Remember when I told you about adding icons to your Services to make them clearer and prettier? Well, I wanted to store those Services in the cloud for easy access from any computer. When I copied them to my local iDisk, everything appeared to be just fine.

But as soon as the sync began, the icons and labels all started disappearing.

In the end, MobileMe stripped off all the labels and icons from my files.

I'm not sure why Apple's own file syncing service is incapable of handling Mac-specific data, but this works just fine using Dropbox. And Dropbox wins on seamlessness too. So if I ever do have to spend some money on this, that money will be going to Dropbox. It really is a terrific, versatile service, and it's very Mac-compatible.

UPDATE:

Another advantage that Dropbox has over iDisk is its iPhone app. Both let you read documents directly from the online storage, but Dropbox is actually smarter about file types, particularly when it comes to text files. The iDisk app on iPhone will not allow me to read text files that end with the .sh suffix (or, I'd wager, any text file that doesn't end with .txt), saying that the file type is not supported.

Dropbox for iPhone, on the other hand, will recognize those files as text files and display them as such.

This is a big deal for me because one of the main uses I have for these services is constant access to my scripts in the field. They're essentially my shell scripting field reference. But unless they have a .txt suffix, MobileMe's iDisk for iPhone just won't display them.

UPDATE 2:

It turns out that Dropbox isn't perfect with regards to extended attributes after all. While my Dropbox files on my work machine do seem to retain the labels and icons, the same files at home lack these attributes.

Despite these discrepancies, Dropbox considers these files properly synced. Without the reliable retention of icon data, I will not be able to store my icons using Dropbox's service. And the fact that my home and work Dropbox folders are inconsistent does a great deal to reduce my confidence in the overall reliability of the service. Big ticks in Dropbox's CON column, if you ask me. Bummer.

As per one reader's suggestion, I think I will go ahead and try SugarSync.

Add Icons to Services

By default, Services that you create in Automator simply retain the Automator icon — the little robot with the pipe — in the Services menu.

If you want to customize the look of your Services, simply give the actual services on disk (located at ~/Library/Services) a custom icon.

These icons will appear in the Services menu listing, which looks nice and provides visual hints about what the Service does.

My Tech of the Decade

As is the norm for this time of year, the web's full of top ten lists. And the portion of the web I read on a regular basis is naming their top ten tech items of the decade. In that spirit I thought I'd post about the most significant piece of technology from my decade, the one thing that, more than any other, shaped my life for the past ten years. Looking back now I realize that there's only one thing that really qualifies: Mac OS X.

I began seriously using computers late in life. It wasn't until graduate school that I even owned one. In 1998 I got my first computer, a beige G3. The original G3. It ran Mac OS 9, of course, because that's all there was, but I loved it, and it's on this computer that I really cut my systems teeth. It was the beginning of what would later become my career in systems.

A few years later I got my first real systems job at an art school in New York City. In the interview I claimed that there was "no Mac problem I couldn't fix," confident in my knowledge of the simple Mac OS. Little did I know there were major changes on the horizon.

At that job there was a QuickTime Streaming Server under my purview. It ran Mac OS X Server 1.0 and provided me my first experience with what would eventually become Mac OS X. It was very strange looking, had UNIX shell access, and was not like any Mac I was used to using. I can't say I ever quite fully understood that system, but it did give me a good deal of advanced experience, a chance to learn about what was coming. It was like that Terminator arm that Cyberdyne finds that leads to the rise of Skynet and the end of the world. I have to admit, I found it terrifying.

When Mac OS X 10.0 finally came out and I began poking around its internals, that fear crystallized. This was an entirely new animal, far more complex and mysterious than my simple, easy-to-manage Mac OS 9. Suddenly I had our UNIX sysadmin knocking on my door, wanting to look at it, trying to show my how to use the command-line. I would have none of it. "Sure, the command-line is useful," I'd say, "but it's not the Mac way."

Nonetheless, as the new platform progressed I found myself forced to learn more and more about it. And the more I learned, the more I realized some things. For one, it turned out I really liked Mac OS X. Here was a system that, while infinitely more complex than its predecessor, was infinitely more powerful as well. I also realized that, though it was challenging, I was capable of handling the new OS, and capable of learning far more than I ever realized. But, perhaps most importantly, I discovered that I liked learning about Mac OS X. For the first time I realized that I liked systems work in and of itself. That realization, for me, was life changing.

As time went on, the OS became increasingly sophisticated, and I grew more confident in my abilities along with it (these days I'm even pretty proficient in the command-line). Before long I was doing lectures on the OS and had solidified a career in systems administration.

It's now ten years later, and the OS is fully mature, advanced even. And I'm still doing systems administration and finding it fascinating. It's a trend that doesn't seem to have an end in sight.

These days I work for a prominent New York museum and my job involves far less Mac administration and far more programming. I've built a web app and even learned how to program certain video hardware as well as the mysteries and intricacies of serial data. It's all been on-the-job training, learning on the fly. But without those formative experiences with Mac OS X I doubt I'd ever have had the confidence to do what I'm doing now. Mac OS X taught me that I was good with technology, that I enjoyed it, and that my capacity for learning was far greater than I ever realized. These were powerful discoveries that have led me to where I am in life. So I just wanted to acknowledge, here, at the end of the decade, my admiration and affection toward this amazing piece of technology.

A Time Machine Gotcha

Though Time Machine uses hard links to reference files from any point in time without using additional space, changing anything about a file will, obviously, trigger a new copy of said changed file to be backed up to your Time Machine disk. What's perhaps less obvious is that even simply changing the path to the file will trigger a new copy to be made.

To wit: I have a very large folder — about 100GB — full of material that I intend to archive. That folder used to be called "BurnMe." But I recently changed my archiving approach such that the "BurnMe" moniker seemed inappropriate. So I renamed "BurnMe" to "ArchiveMe." My hope was that Time Machine would see that, yes, the folder had changed, but that its contents pointed to already existing files on disk, and that those files hadn't changed and could thus be referenced with a hard link.

Unfortunately, Time Machine isn't that smart. What it actually did was erase some older backups to make room, and then it indeed recopied the entire 100GB folder with the new name. Apparently, changing even the name of a file's enclosing folder counts as a change to the file and will trigger a new backup copy to be created.

My solution to this problem, unfortunately, will be to manage my Time Machine data a bit. It is possible to delete previous Time Machine backups by entering into the interface and right-clicking the file or folder you want to delete, then choosing to "Delete All Backups" of the selected file or folder. From now on I will need to be mindful of name changes to large folders, and be sure and delete the previous backups before (or perhaps after, depending on available space) I do so.

In any case, this is not a huge problem, but it is a minor inconvenience in a process that is meant to be almost entirely hands-off.

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.