Migrate from eMule to aMule

2005-08-26T05:28:11Z

151.37.64.250: This page guides you through the migration from eMule to aMule

<h1 style="text-align: center;">Migrate
from eMule to aMule</h1>
<div style="text-align: left;">Sandro
Tosi, 22 August
2005 

<hr
style="height: 2px; width: 50%; margin-left: 0px; margin-right: auto;"></div>
Here
you'll find some tips about the
migration of configuration & download files from eMule (read
Windows) to aMule (read Linux).
<h3 style="text-align: left;">1.
Brief history</h3>
<a
href="http://www.edonkey.com/">EDonkey</a>
born some years ago
and its great protocol takes itself into the Olympo of file sharing
programs.
Some coders, unsatisfied by
that client, starts developing a new one, called <a
href="http://www.emule-project.net/">eMule</a>.
Its
source code is open, so anyone (able...) can read it and modify it, and
so was. Many client versions came up with patch and new code. Fastly,
the EDonkey guys starts arguing against eMule, blaming that the p2p
network goes constantly slower due to the large number of eMule
clients. After an initial study phase, eMule developers decided to
create a new p2p network leaving EDonkey net alone. It was a success.
The Linux community starts
developing a Linux client able to connect
to eMule network: <a
href="http://www.xmule.ws/">xMule</a>
is born. A
multi p2p network program, <a
href="http://mldonkey.berlios.de/">MLdonkey</a>
added the support to eMule network; even another client came out, <a
href="http://mldonkey.berlios.de/">lmule</a>.
But the winner has yet
to come...
xMule got few coders but a
project starts rumping up: try to port
the changes from eMule to a Linux client: <a
href="http://www.amule.org/">aMule</a>
was born. This fastly became
the de facto standard enkey client for Linux.
 EDonkey is now almost dead,
and wants even to be payed for a
professional version of its client...
<h4>1.1. Migration</h4>
Searching around the web you
will find a lot of people saying the
migration is easy: do not believe them! ;) Or better, it's easy because
temporary file format is compatible, but if we are talking about
configurations files, then the things change.
Below follow my notes about the
migration from eMule to aMule of all
my downloads.
<h3>2. Configuration Files</h3>
There are two important parts
in eMule: the configuration files and
temp/shared files. Let's start with configuration files.
In eMule, these files are store
under config
directory. In aMule,
instead, the configuration files are store under ~/.aMule
directory. So the easy
step is copy the files from the configuration directory of eMule to the
one of aMule. Good, so let's look further...
<h4>2.1. Configuration Files
Automatically Imported</h4>
Many files are read and
correctly imported into aMule; from them we
can find:
<ul style="list-style-type: circle;">
<li>clients.met,
stores the other clients credits. When you download some from a client,
you'll store
in this file how much have you get, so you could promote that client
when it will be in your upload queue;</li>
<li>known.met,
it's where
were stored the downloaded files, the ones printed in green when
searched
again (I really don't know what contains the known2.met
eMule files...);</li>
<li>server.met,
it contains
the saved eMule servers;</li>
<li>ipfilter.dat
and ipfilter_static.dat,
which contain
the IP denied to connect/share files with you;</li>
<li>emfriends.met,
it
contains the friends list;</li>
<li>criptkey.dat
and preferences.dat:
they uniquely identify you for other clients, so you
can keep credits to their side;</li>
<li>other files: key_index.dat,
load_index.dat,
nodes.dat,
preferences.dat,
preferencesKad.dat,
shareddir.dat
and src_index.dat; I
don't know
what's written inside, but I think some are Kademlia related (but they
were written running aMule, so I suppose they are used...).</li>
</ul>
This were the good news, the
bad ones have still to come...
<h4>2.2. Configuration Files NOT
Automatically Imported</h4>
Here start the "war bulletin":
<ul style="list-style-type: circle;">
<li>configuration file: eMule
uses preferences.ini
but aMule uses amule.conf;</li>
<li>categories: they are the
tabs separating files in the download
list; in eMule they are written in the file Category.ini
but aMule writes them
down into amule.conf;</li>
<li>some files in eMule config
directory seems not to be used by
aMule: AC_BootstrapIPs.dat,
AC_IPFilterUpdateURLs.dat,
AC_SearchStrings.dat,
AC_ServerMetURLs.dat,
adresses.dat, fileinfo.ini,
k_index.dat, preferencesK.dat,
s_index.dat,
staticservers.dat,
statistics.ini
and webservices.dat.
I don't know their
function under eMule and maybe some of the above files come from old
eMule installations and know their are not used anymore even by eMule.</li>
</ul>
Further you'll find how I've
imported the missing configurations.
<h3>3. Importing Missing
Configurations</h3>
We have just said that some
configurations are not automatically
loaded into aMule from eMule; try to find out what
we can do to import those data into aMule.
<h4>3.1. Importing Categories</h4>
This command line should help
you generate the categories
information from eMule Category.ini
file (put the commando on the same line):
$
grep -E "^\[Cat|^Title|^Incoming|^Comment|^Color|^a4afPriority"
Category.ini | sed 1,6d | sed 's/#/\\#/g' | sed
's/&/\\&/g' |
sed 's/a4afPriority/Priority/g'
this escapes even # and
& characters, because I've got in my Category.ini
file; maybe there will
be other chars to be escaped that have to included in the script (let
me know, in this case). The script deletes the first 6 rows, that is
the
first category, since it's a dummy one: that category is the first one
in eMule, which contains all/uncategorized/etc files; aMule has its
"all" tab and do not need this entry. Cut&paste the script
result
into amule.conf.
Under [General]
of amule.conf,
you have to define a
variable count
(or change
its value if already defined) with value:
$
echo `grep -c "^\[Cat" Category.ini` -1 | bc
this variable holds the number
of tabs to display: note that even if you have
imported 10 categories, but leave count=1,
only one category will be displayed.
At the end, the categories
configuration in amule.conf should look
like:
[General] 
Count=... 
[Cat\#1] 
Title=... 
Incoming=... 
Comment=... 
Color=... 
Priority=... 
[Cat\#2] 
Title=... 
Incoming=... 
Comment= 
Color=... 
Priority=... 
...
I don't know if importing the
categories before importing the temp
files, they will be classified as in eMule; I've imported temp files
before the categories, but I don't think they will be placed in the
tabs as they were in eMule (if someone can confirm this...).
<h4>3.2. Importing Statistics</h4>
eMule statistics are available
in two distinct files: preferences.ini
and statistics.ini.
I found statistics in the latter file more up-to-date than the
ones
in the former file.
Looking into statistics.ini
you'll find that all statistics are under [Statistics]
tag. Even inside amule.conf
there exists this tag, so the logic conclusion is to copy from statistics.ini
to amule.conf.
In this last file, there are two keys, MaxClientVersions
and DesktopMode,
that should not be deleted (I don't know what they mean, so leave them
where they are...).
Sadly, very few values get
imported: seems only downloaded and uploaded bytes. Maybe it's not the
right place where I've written those keys, or maybe aMule uses other
ones. Only using aMule will reveal it...
<h4>3.4. Other configurations
</h4>
Configurations not yet imported
are the program strictly ones. They are, for example, about the TCP and
UDP port to use, Incoming and Temp directories, network limits and so
on.
Since they are very
client-specific and important for its correct
behavior, I suggest to redefine them by the Preferences
aMule form. Maybe it
would be long and boring, but done it once, they will last forever,
almost... 
If you're a real brave guy, you
can try to import directly some keys
from preferences.ini
to amule.conf,
but then do not argue
it won't work anymore...
<h3>4. Temporary & Sharing
Files</h3>
Temporary files are compatible
between eMule and aMule, so you only
have to set the Temp dir inside aMule (and let it rehash all files) to
have them newly available to download.
For sharing files we have very
few things to do: since they are
already downloaded, the only thing to do is say to aMule where they are
and waiting for rehashing.
<h3>5. At the end...</h3>
Those are the steps I've
followed to migrate from eMule to aMule;
something maybe wrong, and something maybe could be do better, so let
me know any correction/ideas/addition come to your mind.

AMule Project FAQ - User contributions [en]

Migrate from eMule to aMule