17 comments

[ 2.8 ms ] story [ 47.6 ms ] thread
Neither of them really "solve" sync. It's still a problem for complex applications but it works for say, 80% of the solutions.

Anyways I use both and to me they aren't really competitors. Apple doesn't allow stuff like Dropbox to have tight integration with IOS - the biggest value iCloud provides is stuff like Photo syncing, which they aren't even good at.

Funnily enough, what I do is enable iCloud photostream, then store my iPhoto library in Dropbox. The idea is that whenever I take a photo on my iPhone it gets seamlessly synced AND backed up automatically OTA.

People solve sync and make judgements (right or wrong).

That's why version control with full history is infinitely better than sync solutions for file management.

I love Dropbox and use it on all my devices. However, I really wish they would implement permissions on shared folders. It's one of the two most requested features that users want, but they still won't implement it [https://www.dropbox.com/votebox].

As soon as someone comes along that has integrates as seamlessly on my Windows PC, Linux PC and Android phone AND offers permissions on shared folders I will jump ship.

I don't know why, but it actually makes me cross that they aren't listening to their user-base.

I know at least Egnyte (https://www.egnyte.com/) offers folder permissions, and has clients on Windows, Mac, Android, iPhone and iPad. The Linux client is available on some NAS devices and also as a VMWare appliance.

Disclaimer: I work for Egnyte.

Thanks, I'll look into it. Although, am I right in assuming that you don't offer a Linux desktop client?
Right, no Linux desktop client at the moment. I don't think it would be especially difficult to make one, but we'd need enough demand to make the investment.

But having said that, we do provide WebDAV API. Every modern OS I know of, including Linux, can mount a file system over WebDAV. It is not very efficient, and doesn't have all the features you would get with a client, but at least you have access to your files.

Some people actually prefer to use only WebDAV, because that way as soon as you cut network connectivity the files are not accessible (security feature).

(comment deleted)
There are already utilites that allow programs to read PSD files. I used ImageMagick (http://www.imagemagick.org/script/index.php ) in one project and it worked fine for me. Actually, since ImageMagick is licensed under Apache2 my that may very well be what Dropbox is using to accomplish this.
It's not that hard. Basically they're just taking a diff (binary in this case) between the new version and the old version, uploading the diff, and applying it to the version stored on their servers.
binary comparisons are great if you aren't looking at shared files but once you get into a situation where two different people can be editing a file at the same time it really helps to know what data you're dealing with rather than just trying to do a straight binary comparison.

You could very well be right about what they're planning but if that's the way they're going it will end up killing them in the end. As someone who administers Dropbox in a team environment the biggest issue is its creation of "Copy" files whenever there are simultaneous edits.

I mean, think about it. If you're using Photoshop and your edits go into a copy file you basically have to re-do that work. There's no easy way to merge changes (I guess if you were working on different layers but still it's difficult).

Simultaneous editing isn't a problem Dropbox is meant to solve, or is realistically able to solve given the proliferation of document formats out there. For stuff like PSDs, collaborative editing really needs to be baked into the software (and by extension, the document format). For textual data, DVCS works well.
How is it not realistic to solve it? Or more to the point how is sharing suppose to realistically work if you don't. If you say you're going to allow people to share files then you have to account for the very common scenario of simultaneous use.

And (as I said below and got downvoted for) it isn't that hard. We use Dropbox for Teams and I back it up with a custom application using components from a company named Aspose. They allow me to read Office file formats and combine files where needed.

If I can do that in a weekend then why shouldn't Dropbox look into doing it?

Can you explain how you merge two PDF documents that started as a single document, and was edited by two people at the same time? What do you do when they edited the same part of the document? And what about Word, JPEG, MOV etc.?

In source control systems like Subversion the application can usually automatically merge changes that happen in different parts of the document, but will require user intervention to merge conflicts. Merge conflicts can be difficult to resolve even in plain text. I really don't know how you could automate that in plain text files, let alone arbitrary file formats.

I almost think you're kidding here. It's called a popup.

You use Dropbox's already existing functionality to make a copy file. You then compare the changes and if they don't conflict you merge the files (while backing up both just in case of error). If they do conflict you send a message to the tray application which displays a popup showing the conflicts and asking for a choice. This isn't rocket science.

There are certainly places where that wouldn't be feasible like video editing. But I don't buy the argument that "because you can't do everything you should do nothing". Again I point out this took me a weekend to do with office documents and I didn't work through the night to accomplish it. So you can't really tell me it's out of the grasp of a company that has millions in funding.

Ok, so you haven't automated merge conflict resolution.

There are also cryptographically signed documents which you cannot merge, because that would break signatures.

So the question is, how much automated merge processing should be done, and how big are the risks in doing so. Even if the system were capable of doing merges for some documents, it would need to have a setting to turn it off. Recovering erroneously merged documents also needs some thinking. And so forth.

So bottom line is I guess we agree that in some cases merges can be done, automated to some level even, but there is a lot of work needed to make it safe, understandable and usable for the majority of users.

See also rsync.
Reading these stories is a bit depressing. Coding since 5? Solving problems with Finder even Apple couldn't figure out? Is this really the level of technical accumen needed to make it in the startup world?