Dropbox
Dropbox is certainly a promising technology—in many ways, what iDisk should have been—but it currently has some serious problems. It does not support Mac resource forks, extended attributes, or packages. Worse, it does not tell you that it doesn’t support these features. It just silently throws away those parts of your files. Until this is fixed, it should only be used by technical users who are sure that these limitations will not cause problems for them.
Update (2010-12-17): Dropbox 1.0.
22 Comments RSS · Twitter
ACLs, extended attributes, resource forks, and just about all other novel filesystem features are usually broken by file archiving tools, even many that are platform-specific.
Even after a lot of improvement Apple still ships plenty of tools that don't handle novel FS features.
It's the nature of the beast, especially when you're supporting multiple platforms. Anything you don't consider transient/losable metadata should always be stored in the file, period. Resource forks are dead for a reason.
I would like to see Apple make zipped bundles opt-in on Mac OS X — it's a little late in the game to be doing it, but it's the right thing to do, and already used on the iPhone.
Fred Blasdel: Disk images, Zip archives, Tar archives, and Time Machine all support resource forks, extended attributes, and packages. iDisk supports resource forks and packages. So I think if you use the built-in tools, these features are usually not broken.
If you use Dropbox, resource forks disappear, packages turn into folders and can no longer be double-clicked, etc. Yes, new files shouldn’t use the resource fork. And yes, this isn’t surprising for a multi-platform product. But most users are not informed about filesystem details, and they should be able to assume that a product marketed in this way will either “just work” or report an error if it can’t.
As noncommittal as it may sound, the Dropbox folks do have Mac specific file system features on their list. There are mentions in the following forum thread.
“ … potentially adding support for syncing xattrs, permissions, resource forks, etc.”
“… it'd be doing both us and you guys a disservice to do so without perfecting other aspects of the client first (namely improving memory usage, performance on huge file sets […] support for resource forks, etc.)”
I’m personally keeping my hopes up.
This is out of date information. Many Mac packages are now handled properly - at least it works on my system. See this thread in the forums:
[...] Michael Tsai’s post yesterday about Dropbox’s lack of support for upper-level file system features in Mac OSX seems to be [...]
Paul G: That thread misleading. They added special-case support for a few common types of packages. Eight months after announcing “first-class treatment of OS X packages” there is still no generalized support for packages, nor even special-case support for all of the OS’s built-in package types.
In many ways, the most useful type to support would be .sparsebundle because (a) it lets you encrypt your data before sending it to Dropbox, and (b) files within a sparse bundle will retain all of their Mac metadata. However, as of the 11/25 forum build, sparse bundles still don’t work with Dropbox. You end up with a folder that can’t be opened as a disk image. Even .rtfd, which is perhaps the most basic type of package, is treated as a folder in the Web interface.
It’s unfortunate that Dropbox is not up front about the kinds of files and metadata that their product supports. The FAQ says it can store “Anything you could possibly want” but that simply isn’t true.
hi all,
we fully understand how important support for xattrs/resource forks is and we will likely be adding all the support you're looking for. unfortunately, I think some may be glossing over the difficulty of adding this functionality (in a reliable way) to a cross platform tool like dropbox.
suppose you have a folder synced between a mac and linux machine and you have xattrs set on some files in this folder (lets say spotlight comments). now, suppose the folder was renamed on your linux machine. dropbox sees this as a delete of x files and an add of x files since there's no 100% reliable way to trap such events as renames (sure inotify gives us the event if dropbox is running, but if the change is done offline, we don't hear about it.) this means that the only way to maintain this metadata is by storing them on every filesystem's xattrs. unfortunately, not every filesystem properly supports xattrs (for example on ubuntu, I believe, by default, filesystems are not mounted with xattrs support).
anyway, the point here is that it's non-trivial to support this functionality and while there are solutions that get us 90% the way there, that's not what what we're going for :-). It upsets me that the implication is that we're intentionally hiding this information. we are incredibly transparent with our users (just check out our forums) and will gladly take ideas on where/how to make this information more accessible. unfortunately, most users don't understand what xattrs/resource forks are, so edifying the world about them is a bit farfetched ;).
as a sidenote: I agree the phrase 'first-class treatment' was misleading -- going to fix that now.
Arash: First, I appreciate your responding in detail here. For the resource forks and xattrs, I understand and agree that it’s not an easy problem to solve. For packages, it seems to me that since Mac OS X can tell you which folders are packages, you should have the information that you need to support all package types, rather than a hard-coded list, if they’re uploaded by the Mac client. Of course, as a developer I also know that things are often not as simple as they seem.
I’m not accusing you of having bad intentions, but I think the current presentation of this information is inadequate. I briefly checked out Dropbox when it first became available, because it sounded cool, although I didn’t end up using it because I don’t need this sort of syncing myself. The next time I heard about it was when one of my customers complained that my application was incompatible with it. It had saved a file (using Apple’s sparse bundle package format) that became unopenable after syncing with Dropbox.
I went to your site, but there’s almost no information there unless one has an account. I searched Google, but didn’t find anything. I downloaded and installed Dropbox and did not find the information in the Read Me or the installer. After creating an account, I logged in and saw the FAQ and forums. The FAQ does not list any limitations on the data that can be stored in Dropbox. None of the sticky threads, including the one about known issues, mentioned the problem. I did a search and found the thread where you talked about already adding “first-class treatment of OS X packages.” Then I found a thread where other users reported problems with sparse bundle images. Some time later I found threads mentioning resource forks and xattrs. My conclusion is that no one is going to find this information unless they’re really looking for it. As you note, most users don’t know what these features are—therefore, they won’t even be looking.
The beauty of Dropbox is that it’s so transparent. To the user, it does not look like data is being transferred. There’s no “archive” command, no dragging to a server or disk window, etc. There’s just this magic folder that’s always in sync. This is also the danger because it sets the expectation that everything will “just work.” Mac users have historically not needed to know about resource forks. They’re automatically handled when archiving files, sending them via e-mail, even preserved (as ._ files) when copying to an iDisk or FAT16 volume. Dropbox gives no indication that it’s any different.
Here are some concrete suggestions:
1. Have a list of the known limitations that’s accessible before downloading the software, or at least in a Read Me before installing it.
2. Link to this list from the FAQ.
3. Make the forum accessible without a login and indexable by Google.
4. Information in the forum doesn’t count as being available if finding it requires searching for an obscure technical term or reading through pages of posts.
5. Since most users won’t read this information or know what it means, Dropbox should present a warning message when syncing a file whose data cannot be fully preserved.
thanks for the suggestions, michael -- we'll be working on making this information more accessible (starting this week) and more importantly, solving the core problem :).
Hey, I have a problem,
Everytime I drop something in my drop box it shows as offline on the other systems... but seems to be fine on mine! the original system is an emac and the one where i tried to open the files are a mac g5 tower!
Help
Having to create a login to simply _read_ the contents of dropboxes' support and bug forums is not good. That needs fixing. It indeed makes IT folks wonder if they are hiding something, even if that is not dropboxes' intent to hide something.
hi b,
we're not hiding anything :-). the forum login is integrated with dropbox logins so that users don't have to go through a registration process to post. it'd be a bit of work to support guest logins, but it's on the TODO list.
JungleDisk supports MAc OS X packages and resource forks NOW. And it syncs between multiple machines, Mac, Linux, and Windows. And you pay for only what you store. And it uses Rackspace Cloud or S3 for storage, both bulletproof industry leaders.
And it's supported Mac since Day 1. Mac users aren't second-class citizens.
Incidentally, SugarSync has the same problem with packages and resource forks. But they don't tell you that up front. It's buried somewhere in a forum. I lost an entire iPhoto library. 20 gigs gone because I was trying to keep my photo library safe by backing it up.
I recently dived into the whole HFS/metadata complex and found that sparsebundles will be handled correctly in Snow Leopard, regardless of the bundle bit in com.apple.FinderInfo, as long as they carry the .sparsebundle extension. You can easily fix "corrupted" bundles by adding this extension.
I sync'ed an encrypted sparsebundle with DropBox for several months now, and I had to restore it via the web interface once during that period. The zipped copy obtained from DropBox worked just fine.
[...] mode, where it didn’t load its code into the Finder. And I think that the company has been irresponsible with their users’ resource forks and metadata (and also with disclosing which parts of the [...]
[...] should either be changed or clearly disclosed and made a preference. The FAQ has since been changed to say: All transmission of file data occurs [...]
[...] and the fact that you can still access your data after resetting your password. However, this is another instance of Dropbox not communicating well, with the result being that most people think it works [...]
[...] still think Dropbox could be more transparent. In the past, they posted important stuff only in the private forum. This was posted on the public blog, but people who would want to know about this don’t [...]
[...] following metadata: label, creation date, extended attributes, locked flag, invisible flag. Dropbox initially had problems with these as well, but as of version 1.0 it handles them properly. (The test file [...]
