Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
I have this same problem with new edonkey! ed2k-gt-gui 0.63 and edonkeclc!
Who know how to remove this problem??
If I use a link to start a download of a large (2G above) file - yes , it never completes properly. You will see a problem immediately as the file size is not recognized/displayed correctly (e.g link shows the size is 5.1G, but the ed2k download window will diplay 2G).
If I search for the same(!) file, and do start the download from the search window - there is no problem. Downloads and complets perfect, no matter how large.
Oh, that is an interesting observation. Thanks, I'll look into that.
Tim, this is true today for the newer linux edonkeyclc1.3.0, or has been solved in 0.53.3 time ago?
Never downloaded a file >2GB, at most just a little below this size. But just now have one over 2.5GB downloading with edonkeyclc1.3.0, and all the sizes are shown just right with the Windows GUI v0.64 with a link started via the gui, not from the search window, but direct input. The actual completed size right know is a bit over 1GB, so still can't know much more.
Well, certainly seems that I'm having some kind of problem with large files with linux edonkeyclc v1.3.0 / windows gui 0.64, (core is using glibc-2.3.2-101 that support LFS) and a custom linux kernel 2.2.26. Guess that the problem is being caused by the old kernel, but have readed somewhere that newest 2.2.x kernels should do fine when patched.
The x.part file size is 2.147.483.647 bytes (=2*2^30-1 or 2GiB-1) and there is plenty of errors shown in the gui log similar to:
Error validating crumb: filename (-1444663296--1444176896)
The sizes in the gui window are shown right, but that the part file size is truncated at 2GiB-1 is to suspect that there is someting wrong with the core being unable to read past 2GiB.
I'm right and the culprit is the linux kernel?. Any idea before had to move the incomplete file to an XP and continue it from there?.
To be honest, I have no idea.
I could never reproduce the problem locally, which makes it even more of a pain to fix than it already is otherwise. With a 2.2.x kernel, all bets are off IMHO, even more so with a highly-customised LSF system. Truth is, that kind of configuration is just not supportable (for me at least), and I don't know enough about this stuff and how it was supposed to work and did actually work in ancient kernels to make it worthwhile investigating for me (and I don't really have time for edonkey stuff at the moment anyway unfortunately).
In other words: copying the file to an XP partition (or to a box with a current ubuntu/debian/fedora system) is probably your best bet :-)
Just stop using edonkey, its crap and under-developed.
Try eMule, works for Linux and Windoze.
¿There is a comandline version of eMule?.
The edonkeyclc1.3.0 can run on a pentium 200 with only 64M and controlled with the gui. The alternative, aMule doesn't run as smooth as it.
If you have such an commandline eMule, then let us know. If not, then please don't talk about things your are not using.
You guys are quite right, this isn't a problem with edonkeyclc, but ed2k_gui.
For thoose who got the guts for it, you can change the code in ed2k_gui/misc.c on line 1269 From :
*size = atoi(sizepos);
*size = strtoul(sizepos,(char **)NULL, 10);
The problem is that atoi/atol can't convert strings to heigher than 2GB. So what you do is to make a long unsigned integer. It can hold up to 4GB. The target should be to make a even longer integer, but for now it works. This only an issue in unix, and not on Windows.
This has been fixed in CVS now (finally).