When is this useful?
Allthough aMule uses a standard temp file format, this incompatibility issue might happen if you are switching from MlDonkey, eDonkey2000 and some strange xMule versions. This is because these clients use strange temp file formats non-compatible with other client's format (such as eMule's).
Once the testing field is set up, you have two ways to move on. Choose whatever way suits better your needs:
- Search (with a local search), in your aMule client, one-by-one for all the files you were downloading with your old client and go adding them to the download queue.
- Go to your old client and copy the ed2k links of the files in the download queue one-by-one and go adding them into aMule.
Since it's a local connection, the transfer will be almost as fast as copying the temp files from one place to another.
This is very fast, since it will most usually be done on a single machine or between two computers in a same local network.
But the most important advantage is that this method is universal: It makes temp file conversion possible between any two (or even more!) ed2k clients, since they all know the same protocol.
Whether this is a big or a little problem is absolutely random. in 90% of the cases, this will suppose loosing about 5% of the data or less. But if you are downloading lots of little files (less than 10MB for example) the loss could come up to 90% (or even 100% in some few extreme cases).
Also, you should notice that this will need additional hard disk space (for the original and the new temp file). The amount of disk space needed can be reduced by importing one file after the other in a queue and go deleting the original temp files.
You can use aMule's optimized import tool, although it only supports some clients' temp files.
You can also check the script at src/utils/scripts/mldonkey_importer.pl from aMule's sources to import mldonkey's temp files.