Tagged: Qt

Bitcasa: First Impressions


I got my invite for the Bitcasa beta last week but only got around to installing it yesterday. I’ve only used it sparingly thus far. If you are in a hurry, here’s the TL;DR version:

  • Users might find the “cloudify” model confusing
  • Built using osxfuse (not to be confused with MacFUSE) and Qt
  • Infinite storage sounds too good to be true. What’s the catch?
  • Building trust with users will take time

Cloudification and Confusion

Here’s Bitcasa on what cloudify does:

When a folder is Cloudified, a corresponding virtual folder is created on the Bitcasa server and the contents of your local folder are copied up to the server. When Connected to the Bitcasa server, any changes or additions to the folder will live on the server. When not Connected to the Bitcasa server, any changes or addition to the folder will live locally.

Just think about that for a second. The “cloudify” model sounds great in principle, but it does add a lot of complexity in terms of how users interact with the system. For instance, when I’m offline and make changes to one of my cloudified folders, that change happens presumably locally. I would assume that when I come back online, these changes are synced back to Bitcasa ala Dropbox. But what if I accidentally disconnect a folder, make some changes and then reconnect — per the FAQ, the changes made locally won’t be synced.

The consumer cloud storage is fairly mature right now and one can learn a lot by looking at how people respond to other systems. This thread on Quora is particularly insightful: again and again, simplicity comes up as one of the key reasons behind Dropbox’s success.

My prediction is that Bitcasa’s cloudify feature will be leveraged primarily by power users and the rest would end up using the default Bitcasa folder, Dropbox style.

Nuts and Bolts

Bitcasa seems to be built primarily using Qt. This isn’t a surprise: Qt is a mature, open source and cross-platform library.

$ otool -L Bitcasa
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
 /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
 /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
 @executable_path/../Frameworks/libmacfuse_i64.2.dylib (compatibility version 10.0.0, current version 2.0.0)
 /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0)
 /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0)
 @executable_path/../Frameworks/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.7.0, current version 4.7.4)
 @executable_path/../Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.7.0, current version 4.7.4)
 @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.4)
 @executable_path/../Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.4)
 @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.4)
 /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
 /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0)

$ mount
Sample Videos on /Users/diwaker/Bitcasa/Sample Videos (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker)
TryBitcasa on /Users/diwaker/TryBitcasa (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker)
TryBitcasaDedup on /Users/diwaker/TryBitcasaDedup (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker)

Note further that Bitcasa represents “connected” folders as mount points over the existing folders. This is why when you disconnect a folder and make changes, they won’t propagate to Bitcasa’s copy of that folder. They are using osxfuse which implies that Bitcasa is intercepting file system calls; this is in contrast to Dropbox-like systems that detect changes to the local filesystem asynchronously. I haven’t compared fine-grained read/write performance just yet.

Here’s a snapshot of the Bitcasa Folders UI:

Bitcasa also does some deduplication. Uploading 100MB of mostly random data took around 4 minutes on a pretty fat pipe which isnt’ bad at all. Copying that data back out took just as long, if not longer. A copy of the same folder took less than 10 seconds to cloudify!


Much has been said about Bitcasa’s security. However, most of the articles are concerned with a specific dimension of security: encryption.

A detailed discussion of Bitcasa’s security in general and encryption, in particular, deserves a post of its own. For now, suffice to say that even after several years of user experience, Dropbox still hit some pretty nasty security snafus in 2011. Like a lot of you, I’m very concerned about security, especially with a service that is offering me infinite storage for free! It takes time to build trust with your users — there’s no short cut.

Overall, Bitcasa is definitely interesting. Dropbox was almost beginning to monopolize the consumer cloud storage market, so some good competition will hopefully benefit the end users in the long run.