Weekly Edition
Return to the Development page
| |||||||||||||
Reopening iFolderNovell created the file sharing and synchronization tool iFolder years before it began the acquisitions that transformed the company into a major open source vendor. After it entered the Linux market, Novell placed the iFolder code under the GPL, but by 2007 the project was receiving little attention. Commercial packages continued to be available as part of Novell's Kablink groupware product, but source code releases languished. That made it a surprise when Novell resurrected iFolder in April of this year, posting new client and server packages for Linux, and clients for Windows and Mac OS X. iFolder allows you to connect a local folder on your computer to a remote synchronization server. Every few seconds, the iFolder program on your computer detects whether any of the files have changed, and, if they have, uploads the updated files in the background. You can continue to work offline (such as while traveling), and iFolder will re-sync with the server the next time you reconnect. Plus, businesses and workgroups can use iFolder to share the same folder with multiple users, creating an automatically synchronized shared work space that is also backed up with remote storage. The Comeback KidAlthough the continued availability of the source code is an oft-cited advantage to free software, it is still rare to for a dormant project to suddenly return to life — even more so when it is a commercially-sponsored project and the economy is down. Novell's iFolder project leader Brent McConnell said that a lot of voices inside the company pushed for the project to be revived, both because they believe it is valuable to the open source community and because it is a viable product for enterprise customers. "We think that it's a superior tool," he said, adding, "We also want to move it forward as an open project and see where the community takes it." One of the voices inside Novell championing iFolder's cause belonged to OpenSUSE community manager Joe "Zonker" Brockmeier. In addition to believing in the value of the technology itself, Brockmeier said that he and others in the open source community at Novell felt it was very important that the company devote resources to an open source iFolder effort because not doing so would mean going back on the commitment made when the project was opened up. McConnell echoed that sentiment, noting that Novell took criticism for not releasing iFolder source code as quickly as many would have liked, and admitting that such criticism was probably justly due. However, he added, Novell has committed resources to managing iFolder just as it has to other community open source projects like OpenSUSE. "I hope that the community sees this as a strong signal that we're committed to the project and building community around iFolder." The basicsiFolder uses a client-server model to replicate a shared folder over the network. The replication can be between a single client and the server, thus serving as a remote backup, or it can share the same folder between multiple clients, enabling multi-user collaboration. In both cases, the system automatically tracks changes to the folder's contents and transparently synchronizes them, resolving conflicting change sets from different clients on the server side. In addition, unlike network-mounted storage, iFolder's client-side contents are locally stored in the client's filesystem, so editing, new file creation, and file deletion continue to function in disconnected mode. The iFolder server runs on top of Apache, and can optionally use SSL encryption for client-server transfers. User accounts are managed through the server, with support for access control lists on each iFolder's contents, storage quotas per account, and integration of user accounts with an LDAP server. The client side code is a small Mono application that handles authentication to the server, computes hashes of shared files to detect changes, and transfers changed files between the client and the server. The actual client-side files are local, and both their location in the filesystem and the underlying disk filesystem used are immaterial. Users can also connect to the server via a web interface and access the server's copy of their files without using the iFolder client. April's release of iFolder is designated version 3.7.2. The server package is available for OpenSUSE 10.3 and SUSE Linux Enterprise Server (SLES) 10 in 32-bit and 64-bit editions for both. It requires Apache 2, OpenSSL, and Mono 1.2.6. The client package is also available for OpenSUSE 10.3 and SLES 10 in 32 and 64-bits, as well as for Windows XP, 32-bit and 64-bit Windows Vista, Mac OS X 10.4.11 and Mac OS X 10.5. The Windows builds work with Microsoft's .NET, while the Linux and Mac builds require Novell's Mono version 1.2.6. iFolder compared to other systemsiFolder is not the only distributed or collaborative storage solution available for Linux, of course, but several features distinguish it from alternative lower-level systems and commercial products. Basic network file systems like Samba and NFS are designed to work over a LAN. WebDAV, on the other hand, is based on HTTP, can be secured with SSL encryption, and allows for multiple users to connect to the same set of files. But unlike iFolder, WebDAV maintains only one copy of the shared folder and files — the original on the server. That prevents clients from continuing to work while disconnected from the server or the network as a whole. There are distributed filesystems designed to operate in disconnected mode and with free software Linux implementations, notably the Coda project from Carnegie Mellon University. Coda is a complete filesystem rather than an add-on utility, however, and requires kernel-level support on the client machine. The Linux kernel has supported Coda for years, and it is supported by FreeBSD and NetBSD, but not by Windows or Mac OS X. Furthermore, Coda's disconnected mode operates by maintaining a temporary local cache on the client; when connected to the server, the server's copy of the file is used, just as in NFS, WebDAV, or other networked file systems. Brockmeier said that he regards Dropbox as the only real comparable product on the market. Dropbox is a commercial service that provides shared online storage (with tiered free and paid accounts), but although its client-side program for GNOME's Nautilus file manager is open source, the server is proprietary. The futureThe current 3.7.2 release of iFolder is a welcome sight after more than a year without an update. But the Linux binaries are only available for SUSE, and the supported version — 10.3 — is no longer current. The Mono dependency is also old; iFolder 3.7.2 requires Mono 1.2.6, which was released in 2007. Novell has set up project hosting at SourceForge.net, including user forums and wiki documentation, but so far the source code is only available through a Subversion checkout. McConnell said that Novell is committed to the project, however, and that reviving the project was slowed down by the need to do a full code review. He also posted to the project's user forum that work was underway to package the code for other Linux distributions, starting with OpenSUSE 11 and Debian. The team is also working to update the software for compatibility with more recent releases of Mono, but improving support for other distributions will move much faster if those distributions join in the effort. There was widespread excitement in the Linux community when Novell announced the return of iFolder as an open source project. Hopefully that enthusiasm will be matched by contribution, when you combine its transparent replication, disconnected operation, and fine-grained user account management, iFolder holds significant promise. (Log in to post comments)
Reopening iFolder Posted Apr 30, 2009 1:49 UTC (Thu) by elanthis (guest, #6227) [Link]
I hate to say it, but they'll get more support if they move away from Mono. Too many people are still paranoid about it, unfortunately.
Reopening iFolder Posted Apr 30, 2009 5:41 UTC (Thu) by ivazquez (guest, #50782) [Link]
But they're not. Which is reason enough to them to not move.
Reopening iFolder Posted Apr 30, 2009 7:02 UTC (Thu) by sitaram (subscriber, #5959) [Link]
I hate to make this a "yes. No. yes too..." kind of discussion, but I will not use Mono, and will not allow any mono libs on any system that I am responsible for. I will not use Ubuntu or indeed most Gnome-based distros; sticking to the KDE types instead.
I have been told that this is FUD; I smile and reply that if so, there is a certain poetic justice in it :-)
Reopening iFolder Posted Apr 30, 2009 7:15 UTC (Thu) by ivazquez (guest, #50782) [Link] You don't really think you're safe, do you?
Reopening iFolder Posted Apr 30, 2009 21:30 UTC (Thu) by bronson (subscriber, #4806) [Link]
Who uses synapse?
Reopening iFolder Posted Apr 30, 2009 23:12 UTC (Thu) by ivazquez (guest, #50782) [Link]
Sometimes "who uses it?" is a less important question than "does it exist?". I'm fairly sure that KDE will be used by an increasing number of Windows expatriates that know C#.
Reopening iFolder Posted May 1, 2009 4:38 UTC (Fri) by sitaram (subscriber, #5959) [Link]
...and if and when that happens, I will move to something else.
Right now, a default install (important to me since I maintain a handful of machines for friends, relations, etc) of most KDE-based distros does not include mono. With Gnome I have to go in and manually remove stuff, which is a pain.
There'll always be choice. Even if there is some application for which the only available/usable program is in Mono, the ultimate choice is with me, whether I use it or do without.
As for safety (your earlier comment), I don't know what you mean. Do you mean safety in a legal sense of some kind? I live in a country where most software (outside corporate use) is illegal. I could pirate anything I want and blog about it and nothing would happen.
My attitude is not prompted by worries of any kind. This is purely principle. Hence my statement about the final choice being mine: use it or do without.
Reopening iFolder Posted Apr 30, 2009 14:19 UTC (Thu) by zlynx (subscriber, #2285) [Link]
Samba and Wine have more reason to worry than Mono. LLVM probably violates more virtual machine and compiler patents.
I think using an easy development language like C# will attract more developers than it will turn away.
Reopening iFolder Posted Apr 30, 2009 14:59 UTC (Thu) by elanthis (guest, #6227) [Link]
Don't get me wrong, I agree. I'm frustrated by the fact that so many distros and users avoid Mono like the plague. That doesn't magically make the paranoia irrelevant, though. :/
Reopening iFolder Posted Apr 30, 2009 19:49 UTC (Thu) by drag (subscriber, #31333) [Link]
It's their loss.
They need to look at things rationally and understand that, yes, many things that we take for granted and use in Linux have originated in Microsoft.
Take, for example, AJAX. You know, the technology that is going to finally 'rid us of the Windows desktop' is going to be 'web-based applications'. What allows these things to function is the ability to asynchronously send information to and from the web server using XML objects and Javascript.
You know.. to keep things moving and information being sent to and from your browser without having to refresh for every change. Of course the company that first introduced the async XML calls to the browsers for the purposes of doing online applications was, oh the horror, Microsoft. And those calls are now 'web standards'.
Go figure.
Reopening iFolder Posted Apr 30, 2009 13:14 UTC (Thu) by herodiade (subscriber, #52755) [Link]
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.
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 (subscriber, #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).
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:
Is this it?
> It explicitly tells you to avoid the use of csync for laptops and
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.
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?
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 (subscriber, #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/)" 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.
Dropbox and similar Posted Apr 30, 2009 15:22 UTC (Thu) by Cato (subscriber, #7643) [Link]
Dropbox isn't that useful for Linux, as it doesn't preserve permissions (as I found out to my cost ...), and I found it wasn't possible to get it to work reliably, though others have found it works fine. SpiderOak (see http://spideroak.com) is a lot more useful for me - it's a backup client and service primarily, but has recently introduced syncing. Pricing is similar to Dropbox so it's reasonable for individual home users.
For my needs this is a lot more useful - SpiderOak also doesn't force all clients to sync with all data on all other clients, which is what Dropbox does, and causes performance and security issues if you have some large data that should not be present on all clients. It has a Python client so you can use the same tool on Mac or Windows, and it also works nicely under KDE (and probably GNOME) without mandating use of Nautilus.
Dropbox and similar Posted Apr 30, 2009 21:02 UTC (Thu) by bronson (subscriber, #4806) [Link]
Spideroak is pretty cool. I just tried it out based on your recommendation. Some thoughts:
- Setting up synchronized folders is more of a hassle than it should be
Other than that, no complaints. It's definitely better than Dropbox. Guess I'll try ifolder next.
Reopening iFolder Posted Apr 30, 2009 21:27 UTC (Thu) by bronson (subscriber, #4806) [Link]
I am really surprised, shocked even, that iFolder doesn't do versioning. They don't even mention it in the FAQ. Is there a roadmap somewhere?
The ability to roll backward through time is probably the single biggest feature I would require in such a product. Would I trust it to autosynchronize my files if I couldn't roll back to fix its inevitable mistakes.
Even more important, going back in time is a requirement when collaborating with others. If your coworker can't easily undo your changes, you need to ask permission before making any questionable edits. It bogs the whole process down, making it more painful than collaborating via email attachment.
Is there any chance of versioning being added in the future?
versioning? Posted May 1, 2009 18:26 UTC (Fri) by ndye (subscriber, #9947) [Link]
Versioning is a big miss, thanks for mentioning it.
With sufficient cash (NAS) or cleverness, perhaps the filesystem under the WebDAV server could implement the version control? Guess I need to look over the server-side code, if any.
And how could versioning occur on a (disconnected) client, a virtual filesystem on a folder?
Reopening iFolder Posted Apr 30, 2009 23:17 UTC (Thu) by ssam (subscriber, #46587) [Link]
glad to see this back alive.
i don't like the idea of dropbox, as it is reliant on their servers, and their generosity with the free version. I already have a server with 1TB of storage, and as a bonus half the time i am on a LAN with it which would save bandwidth time etc.
i have tried conduit, but its not quite up to the task.
Reopening iFolder Posted May 1, 2009 9:23 UTC (Fri) by sunny007 (guest, #4676) [Link]
Wow, this sounds like something I've been looking for, for quite a while. I spent quite a while looking for something that would allow me to keep my laptop synced with my server. (A little like roaming profiles on windows). This enables me to have the same folders on the desktop and back everything up in once central location.
I'll have to look into iFolder see if it meets my needs, I'll be very happy if it does.
Reopening iFolder Posted May 6, 2009 12:35 UTC (Wed) by jschrod (subscriber, #1646) [Link]
If it doesn't, take a look at Unison.
http://www.cis.upenn.edu/~bcpierce/unison/
Two-way synchronization that works like a charm. I keep my laptop data synchronized with our file server's content since years; it just works.
Reopening iFolder Posted May 2, 2009 13:28 UTC (Sat) by asherringham (subscriber, #33251) [Link]
This is very good news and I hope iFolder gets some active development work. The application/competitor I'd like to see it replace is Microsoft Groove :
http://en.wikipedia.org/wiki/Microsoft_Groove
Groove was Ray Ozzie's post-Notes invention and has similar capabilities (a few more I think).
A few years ago I recall looking at iFolder with the same hope I express above, only for it to (seemingly) wither. Here's hoping again.
|
|||||||||||||