I hope that this can be a warning to any of you who may want to try and
attempt upgrading iFolder 3.2 on OES SP2 to iFolder 3.5 (Open Source), as
well as if there are any iFolder developers that could offer assistance on
this issue, it would be greatly appreciated. I'll start with some
background information to give you the history of how this came to be.

We were running iFolder 1.x and upgraded to 2.1 on OES NetWare, and
everything worked flawlessly. The promise of the added enhancements (folder
sharing, multiple folders, etc..) in iFolder 3 were too enticing for us to
wait until Mono was ported to the NetWare kernel and allow for a possible
migration. Since we migrated our users from iFolder 2.x NetWare to iFolder
2.x Linux and then quickly moved people to iFolder 3.x when we discovered
iFolder 2 and 3 didn't play well together on the same box (high processor
utilization rendering the box almost useless when some iFolder 2.x clients
would connect) we have had some issues where n number of items haven't
synchronized on our iFolder 3 clients. I opened a ticket with NTS to help
with the migration / that turned into a ticket with n items not
synchronized. At first this issue was only with one of our users, then
gradually, more and more of the same issue kept cropping up. One of our
users had 1500+ items not synchronized. One of them had @500 items not
synchronized. And then there were the majority that had between 10-35 items
not synchronized. Novell's solution to this problem is this:
This would be an acceptable solution to a highly technical person with a
couple of items not synchronized, but to try and have a user do this to
1500+ items is ridiculous.

I attended BrainShare this last year where iFolder was still featured as an
Enterprise product as part of OES / with Enterprise support. When you call
Novell, you'd hope to get an iFolder support person, not someone who
supports the Apache web server simply because iFolder runs inside of Apache.
Since BrainShare, Novell open-sourced the iFolder Enterprise server and it
seems as if the project has dwindled, of course that's just the perception
of a loyal Novell customer who's getting frustrated with this sort of thing.
So if you sense frustration, you're correct. I asked my technician at NTS
(Novell Technical Support) when we should expect a new version of iFolder
that would resolve the issues we're seeing, and he let me know that I was on
the latest version of iFolder, and that the product has gone into
"Maintenance Mode" explaining that only critical security patches would be
fixed. When I asked when we should expect to see an update for this issue,
he said the workaround in the link above was the resolution, and he wasn't
really at liberty to discuss other aspects of the product relating to
updates, but that we may hear something in 6 months or so. He did a good
job, and really tried to help me with my issue, recommending patches for
novell-lum and other things, so I don't blame him for this problem. I
believe he truly wanted to help us get our issue resolved, there was just
nothing else he could do about it.

Since we currently use other open-source products in our environment (Apache
/ Tomcat, Moodle, Mailman, etc...) and are comfortable with them, I asked
our NTS person if upgrading to the iFolder 3.5 server would resolve our
issues since there wasn't a slated 3.2 fix in the foreseeable future. I
sent him this in an e-mail :

"...Would upgrading to the 3.5 server resolve some of these issues? Can you
upgrade to a 3.5 version from 3.2 that comes with OES even if it's 'not
supported'? We currently run several other open-source programs in our
environment and are okay with going that route if it will fix issues...."

And he responded with this:
"...You will see some improvement on the sync issues by upgrading to the
3.5 client. There was one fix that I know of that was related to binary
files, they were causing problems with the synchronization tables. The 3.5
client has been available for a while, to my knowledge that version is
stable. You shouldn't have any problems with the upgrade..."

I responded with:
"...You mention the client, is it okay to upgrade the server?..."

He replied with:
"...With the open source code, you would have to test it first before
putting it into production. I haven't seen any information about changes
with that version, I haven't used that version, so I don't have any
recommendations either way.

You mentioned that the current iFolder is working for most users. Is the
problem with the synchronization not syncing all the files? Did you try
following the information from this link?

In his DEFENSE here, he did say that we would have to try this in a test
environment, which I didn't do because it's something we don't have, and
again, I'm not blaming him.

I responded with:
"...I did look at that link, but it's too complex to have users follow, so
I'm looking for a solution that can be accomplished on the back end.

I subscribed to the following red carpet channels (ZLM), to get the updates
to the server so iFolder 3.5 server could run.
Yes | mono-official-stable | Mono Official - stable
Yes | oes | oes
Yes | oes-edir88 | oes-edir88

Somewhere in the upgrade process, the upgrade deleted all of my iFolder user
data. Now I have an iFolder server with the basic setup, none of the users
are listed, none of their ifolders are listed, and all of my iFolder clients
are unable to login to the server. If I go to the server via command line,
sure enough, all of the ifolder data is GONE.

Just thought you might want to know that in case anyone else should ask if
it's okay to upgrade from iFolder 3.2 to iFolder 3.5.

Since this is now in the open-source arena, can you point me to the
appropriate place to get support for that? I can't seem to find it

In which case he replied:
"...Thanks for the heads up, I'm sorry that it had to come at your expense.
The one good thing about this, is that the users data should still be on
their workstations.

If you decide to continue with iFolder 3.5, the support will come through
the community at, or by subscribing to the
iFolder development discussion at

I am hesitant to make any suggestions about iFolder 3.5, in light of what
has happened. But, once you have the users activated, their files should
sync up to the server they next time they log into iFolder.

Your other option is to remove iFolder from the server completely, and then
re-install iFolder 3.2. With that configuration I can get the back-line,
and developers involved in getting the users data back to the server.

Hopefully the links will help..."

Which brings me here. I'll elaborate a bit further on the upgrade process
now. I started by going to the download page, and downloaded
the RPM's
for iFolder Server 3.5 using wget from the CLI on my OES box. In an attempt
to install some of these rpm's with the -U option, I was informed that I
needed a new simas server and some mono updates. So I subscribed to the
mono-official-stable, oes, and oes-edir88 red carpet channels in ZLM to get
the latest updates. In that process, it updated a smattering of items and
had to remove others also. The red carpet process took a long time when it
got to 99.1% and I was wondering what was taking it so long so I launched
"top" to see the processes using the most processor utilization etc... The
two processes which were consuming most of the system were "rug" and "rm".
At which point I thought, okay "rm" is running because it must be getting
rid of older versions, or something.. That update process finished
successfully, at which point I was able to 'rpm -Uvh
ifolder3-server-3.5.6172.1-1.i586.rpm' and it upgraded successfully.

I opened my iFolder client, and was unable to log in to the server so, I
went to our server url to access the iFolder web interface, which I was also
unable to log into. I had remembered reading about the default username and
password on the 3.5 server, so I tried that and I was able to access the web
interface just fine. It was at this point when I realized that 'something
was rotten in Denmark'. None of my iFolder users were listed, so the user
database wasn't moved, and none of the iFolders were listed, so it appeared
that all of their data was gone. I quickly did a 'df' on the server and saw
that now only 1% of the disk space was being used. I tried to go out to
/var/opt/novell/ifolder3/simias where the user data store used to be
located, but it was GONE. /var/opt/novell was there but ../ifolder3 and
everything after that of course was gone.

So, now I sit here, with a backup tape with all of our iFolder3.2 data on
it, and an iFolder3.5 server in an empty configuration state. I could
follow the NTS persons recommendation, and recover to 3.2, which wouldn't
fix our problems of the user data not synchronizing, or press ahead with 3.5
which doesn't seem to have any LDAP integration yet.

What I'm looking for is if there is an iFolder developer/expert who checks
this support group that NTS pointed me to who could give me some advice on
where to head.

Dennis deBruyn
Senior Network Engineer