SpiderOak Woes

[richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org (Richard Pieri)]

On Apr 11, 2011, at 10:25 PM, Edward Ned Harvey wrote:
> 
> I'm sure you're aware of a bunch of direct competitors of spider oak -
> dropbox, sugarsync, box.net, etc...  But they all require you pay for
> service over a certain level.

Usually by storage.  "The first hit is free." :)

The "problem" is that they all use the same kind of storage foundation such as Amazon S3, Google Storage (RESTful), or the like.  These don't expose file systems directly to the client side which sometimes leads to quirky behavior.  For example, S3 has no concept of directories or folders.  It's a big, flat file system.  The simulation of directories is handled by the client through metadata associated with the stored file data.  I'm currently dealing with Dropbox over a bug that I've discovered where empty folders cannot be permanently purged because there are too many files in them.  Yes, it's a tea/no tea glitch and the S3 side doesn't know what to do with it.

SpiderOak does have one specific, tangible benefit over the other storage providers.  The encryption keys are stored entirely on the clients without any escrow.  Where Dropbox and Sugar can decrypt your files on request from law enforcement, SpiderOak can't.  If you are storing sensitive information on servers that you cannot trust then this is a Big Win.

I'm planning to switch from Dropbox to SpiderOak for file sync.  I just need to wrap my brane around the more backup-oriented design.  It's a different design philosophy than the sync design that Dropbox uses.

--Rich P.