User: Password:
|
|
Subscribe / Log in / New account

Reopening iFolder

Reopening iFolder

Posted Apr 30, 2009 13:14 UTC (Thu) by herodiade (guest, #52755)
Parent article: Reopening iFolder

Am I the only one surprised by this sentence: "Dropbox as the only real comparable product on the market." ?

What about free bidirectional rsync-like synchronisation tools, ie. Unison (http://www.cis.upenn.edu/~bcpierce/unison/) or csync2 (http://oss.linbit.com/csync2/) ?

Also addressing similar needs, maybe worse than iFolder but surely better than the "other systems" cited in this article : all SCM, in particular distributed one like Git or Mercurial do allow "clients continue to work while disconnected from the server or the network as a whole" and doesn't "requires kernel-level support on the client machine" either.

Indeed DSCM (+ properly configured cron/icron/at jobs) do have different strengths (ie. change history, N-way manual merges, ...) and weakness (ie. spreading .git/-like directories all over the place, lack of high level frontend to configure them for such an use, ...), but at least an Unison vs. iFolder feature comparison would be more useful (look, they even are both candidate for the "unexpected programming language choice" ;) than an apple-to-orange comparison with Coda or NFS.

Unrelated question : the article's description make it look like iFolder is re-scanning the whole directory tree at regular intervals.
Can't iFolder just scan once at server connection, then passively monitor & propagate immediately via inotify/gamin/fam ? Else, what the cost in terms of resources (power consumption), and isn't it too much racy ? (risk to loose changes when shutting down laptopA and switching to laptopB, if changes are only looked for and replicated every few minutes) ?


(Log in to post comments)

Reopening iFolder

Posted Apr 30, 2009 15:11 UTC (Thu) by elanthis (guest, #6227) [Link]

"Unison (http://www.cis.upenn.edu/~bcpierce/unison/)"

Nope. It is a single client to single server. iFolder and Dropbox are multi-client to single server. Meaning I can synchronize a folder between my desktop, my laptop, my workstation, and access them via the server's web UI if I'm ever on some other machine.

"csync2 (http://oss.linbit.com/csync2/)"

It explicitly tells you to avoid the use of csync for laptops and desktops. I believe that's because it has very poor offline mode support -- it expects the machines to be connected at all times. (Could be wrong, didn't read much past where it said not to use for laptops.)

"doesn't "requires kernel-level support on the client machine" either."

Yes, actually, it does if you want it to be automatic. I have far better things to do with my life than open a shell and type in a command or three every time I update my resume in Abiword or tweak some financial data in Gnumeric. When I save the file, I expect it to sync automatically. That requires some kind of daemon running using something like inotify so that it can automatically detect the changes and sync for me. Likewise, if I have my laptop and desktop running at the same time and I change a file on my desktop, I would like to see it updated on the laptop without me needing to go tell the laptop explicitly to update.

Unlike DSCM, I don't generally require versioning of said files, though I won't mind if it's there. Dropbox does versioning automatically for example, though I've never needed the functionality.

DSCM's don't really solve the same problems though. They focus on managing a tree of data organized by commit and history. That is massive overkill when all you need is synchronization (even with versioning). It's also a poor fit, because the concept of a "commit" is really out of place here. CVS's per-file commits are actually more appropriate in this case if any SCM is relevant. But on top of all that, the DSCM's don't support the best protocols for these sorts of things. They're optimized for syncing text files (source code mostly) and put a lot of effort into diff calculation and the like which is largely useless for binary files or even most XML file formats. Tools like iFolder additionally take extra care to avoid pounding the hard disk (no DSCM tries to throttle its disk access, for obvious reasons) and to avoid saturating your network connection (which, again, no DSCM does).

"Can't iFolder just scan once at server connection, then passively monitor & propagate immediately via inotify/gamin/fam"

That is precisely what it does, same as the Dropbox client. There are limits to what inotify can handle so it may need to still poll in some cases. That is largely what gamin does for you -- inotify when it can and polling when it can't.

To sum up, one tool does not fit all needs. DSCMs are great for source control. They are not great for general purpose file synchronization. Likewise, iFolder would suck as an SCM. Use the right tool for the job instead of trying to make one tool (even a generally versatile one) fit every single possible slightly related job under the sun.

Reopening iFolder

Posted Apr 30, 2009 18:16 UTC (Thu) by herodiade (guest, #52755) [Link]

> It is a single client to single server. iFolder and Dropbox are multi-client to single server. Meaning I can synchronize a folder between my desktop, my laptop, my workstation, and access them via the server's web UI if I'm ever on some other machine.

Thanks for the precision. It's true this mode of operation isn't the natural use case for Unison, but they claim it can be done (they recommend using a centralised topology though, in this case, so we would loose their nice merge/conflict resolution features).
http://www.cis.upenn.edu/~bcpierce/unison/download/releas...

My first impression (haven't tried iFolder actually) would be that the strength of both tool may be different but complementary. Correct me if I'm wrong:
* Unison for multiway sync (sync your laptop and desktop in both direction, without the need for a server). Ie. typical home user.
* iFolder would be better designed for star topology (multiple desktops with a central server) replication, with strong centralized authentication management. Ie. typical needs for office user.

Is this it?

> It explicitly tells you to avoid the use of csync for laptops and
> desktops. I believe that's because it has very poor offline mode support
> -- it expects the machines to be connected at all times.

It's more because it doesn't offer users a change to handle conflicts resolution. Ie. you configure it so if in doubt (simultaneous changes on the same file get synchronised), one server is always right and the changes from the other would be lost (and similar algos), while Unison would ask the user. This indeed is not the best option for everyone, and is more targeted for servers (where you may prefer things handled automatically).

> Yes, actually, it does if you want it to be automatic.
[...]
> That requires some kind of daemon running using something like inotify
> so that it can automatically detect the changes and sync for me

Good opportunity to plug "incron", a nice cron-like system that triggers commands on file changes events (rather than time events) ;). But you're right, the other way around (pulling changes from a distant system) would be best handled by a dedicated protocol (rather than regularly launching the sync tool). And you're right about the fact that without a small kernel support (like inotify api), those tools do have to fallback on the ressource intensive "scan in loop" way of things. I would still distinguish such a "small kernel help when available" from the kernel requirements examples mentioned in the article (Coda,...).

> They're optimized for syncing text files (source code mostly) and put a lot of effort into diff calculation and the like which is largely useless for binary files

Hmm, I for one do mostly use text files in my home (except for browser cache and the like, which I wouln't like to synchronize), so that's a valid use case, and that's why I tried git-home-history (and still use etckeeper). I have to agree, it's probably not a mainstream use case, and most people would use an office suite producing binaries rather than vim and text files :).

Which lead to the observation that git and the like needs to progress in this space before they can be useful for non geeks users daily files operations (ie. a pluggable architecture to diff properly opendocument zipped files and similars). See how many people starts to think about misusing or improving git so it can be a good backup solution? and remember Lary McVoy (of BitKeeper fame) saying that, outside the opensource community, there was a huge demand for good binary files handling in SCM?
Your "one tool does not fit all needs" is wise but frustrating.

Anyway, for things like /etc directory and other folders using mostly text files, aided-SCM (like etckeeper) may do an useful job, and that's why I was surprised to see them factored out of the discussion in the article (as opposed to NFS or Coda). Which was by no way claiming they are better than iFolder for all use cases ;)

Reopening iFolder

Posted Apr 30, 2009 20:29 UTC (Thu) by drag (guest, #31333) [Link]

I've used Unision for a serious effort for some time.

And, indeed, it's only really useful for performing sync of two directories. When you get up to 3 or 4 systems your trying to keep in sync it becomes very tedious and very time consuming. Pretty much worthless, unfrotunately.

It's easier at that point to just use a rysnc script to sync everything to a central server then pull down the changes. Even then it becomes very difficult to delete, move, or rename files effectively. Basically it boils down to copying using rsync then manually carrying out delete/rename/move operations. It can't really be automatically handled unless your very clever at scripting.

Reopening iFolder

Posted Apr 30, 2009 20:45 UTC (Thu) by bfields (subscriber, #19510) [Link]

"Unison (http://www.cis.upenn.edu/~bcpierce/unison/)"

Nope. It is a single client to single server. iFolder and Dropbox are multi-client to single server. Meaning I can synchronize a folder between my desktop, my laptop, my workstation, and access them via the server's web UI if I'm ever on some other machine.

I don't understand. I've been doing exactly that with unison for years.

Reopening iFolder

Posted Apr 30, 2009 15:25 UTC (Thu) by Cato (subscriber, #7643) [Link]

Dropbox is a service as well as a tool. No matter how great the tool, not everyone wants to implement their own service even if you do have a web hosting account with ample capacity. It's like the difference between using a hosted email service and setting up your own mail server.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds