Reopening iFolder
Novell 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 Kid
Although 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 basics
iFolder 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 systems
iFolder 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 future
The 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.
| Index entries for this article | |
|---|---|
| GuestArticles | Willis, Nathan |
Posted Apr 30, 2009 1:49 UTC (Thu)
by elanthis (guest, #6227)
[Link] (9 responses)
Posted Apr 30, 2009 5:41 UTC (Thu)
by ivazquez (guest, #50782)
[Link] (5 responses)
Posted Apr 30, 2009 7:02 UTC (Thu)
by sitaram (guest, #5959)
[Link] (4 responses)
I have been told that this is FUD; I smile and reply that if so, there is a certain poetic justice in it :-)
Posted Apr 30, 2009 7:15 UTC (Thu)
by ivazquez (guest, #50782)
[Link] (3 responses)
Posted Apr 30, 2009 21:30 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Apr 30, 2009 23:12 UTC (Thu)
by ivazquez (guest, #50782)
[Link] (1 responses)
Posted May 1, 2009 4:38 UTC (Fri)
by sitaram (guest, #5959)
[Link]
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.
Posted Apr 30, 2009 14:19 UTC (Thu)
by zlynx (guest, #2285)
[Link] (2 responses)
I think using an easy development language like C# will attract more developers than it will turn away.
Posted Apr 30, 2009 14:59 UTC (Thu)
by elanthis (guest, #6227)
[Link] (1 responses)
Posted Apr 30, 2009 19:49 UTC (Thu)
by drag (guest, #31333)
[Link]
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.
Posted Apr 30, 2009 13:14 UTC (Thu)
by herodiade (guest, #52755)
[Link] (5 responses)
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.
Posted Apr 30, 2009 15:11 UTC (Thu)
by elanthis (guest, #6227)
[Link] (3 responses)
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.
Posted Apr 30, 2009 18:16 UTC (Thu)
by herodiade (guest, #52755)
[Link] (1 responses)
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 ;)
Posted Apr 30, 2009 20:29 UTC (Thu)
by drag (guest, #31333)
[Link]
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.
Posted Apr 30, 2009 20:45 UTC (Thu)
by bfields (subscriber, #19510)
[Link]
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.
Posted Apr 30, 2009 15:25 UTC (Thu)
by Cato (guest, #7643)
[Link]
Posted Apr 30, 2009 15:22 UTC (Thu)
by Cato (guest, #7643)
[Link] (1 responses)
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.
Posted Apr 30, 2009 21:02 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
- 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.
Posted Apr 30, 2009 21:27 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (1 responses)
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?
Posted May 1, 2009 18:26 UTC (Fri)
by ndye (guest, #9947)
[Link]
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?
Posted Apr 30, 2009 23:17 UTC (Thu)
by ssam (guest, #46587)
[Link]
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.
Posted May 1, 2009 9:23 UTC (Fri)
by sunny007 (guest, #4676)
[Link] (1 responses)
I'll have to look into iFolder see if it meets my needs, I'll be very happy if it does.
Posted May 6, 2009 12:35 UTC (Wed)
by jschrod (subscriber, #1646)
[Link]
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.
Posted May 2, 2009 13:28 UTC (Sat)
by asherringham (guest, #33251)
[Link]
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.
Reopening iFolder
Reopening iFolder
Reopening iFolder
You don't really think you're safe, do you?
Reopening iFolder
Reopening iFolder
Reopening iFolder
Reopening iFolder
Reopening iFolder
Reopening iFolder
Reopening iFolder
Reopening iFolder
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) ?
Reopening iFolder
Reopening iFolder
http://www.cis.upenn.edu/~bcpierce/unison/download/releas...
* 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.
> desktops. I believe that's because it has very poor offline mode support
> -- it expects the machines to be connected at all times.
[...]
> That requires some kind of daemon running using something like inotify
> so that it can automatically detect the changes and sync for me
Your "one tool does not fit all needs" is wise but frustrating.
Reopening iFolder
Reopening iFolder
"Unison (http://www.cis.upenn.edu/~bcpierce/unison/)"
Reopening iFolder
Dropbox and similar
Dropbox and similar
- It only scans once every hour. That's a pretty big window to lose data!
- It can't scan any faster than every 5 minutes.
- The UI is graphically heavy and feels slow (especially the tray menu)
Reopening iFolder
versioning?
Reopening iFolder
Reopening iFolder
Reopening iFolder
http://www.cis.upenn.edu/~bcpierce/unison/
Reopening iFolder