Thu 30 Jun 2005 12:13:22 PM UTC, comment #16:
Closing this, duplicate of bug #12910
|
Thu 30 Jun 2005 01:01:32 AM UTC, comment #15:
@JongAm Park
what is the output of mlnet at start up regarding the current locale and the encoding list?
Can your system support the characters replaced by '_'?
|
Wed 29 Jun 2005 03:40:52 AM UTC, comment #14:
OK. I tested it.
The file names are still ----- where the characters are not English.
|
Sun 26 Jun 2005 10:29:25 AM UTC, comment #13:
@Sylvian: I think 2.5.30.16 has reached a state which is more
stable than 2.5.28.1
@JongAm Park: It should be possible to switch between current
Knocker 2.5.16 releases and 2.5.30.16, but keep a copy of your
ini files, just to be sure.
|
Sun 26 Jun 2005 01:18:02 AM UTC, comment #12:
This bug is probably the same bug as bug #12910 .
Can anybody tell me if there is no changes in mldonkey's setup files?
Sometimes, they are changed. So, when I try new version, I lost all files being downloaded.
If it is not changed, I can test it safely.
Thanks.
|
Sat 25 Jun 2005 11:26:59 PM UTC, comment #11:
Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://download.berlios.de/pub/mldonkey/spiralvoice/
|
Sun 08 May 2005 12:45:40 PM UTC, comment #10:
Please try 2.5.30.15 + patch #3984 which should solve the commit naming problem.
|
Sun 08 May 2005 02:07:22 AM UTC, comment #9:
Hi. I tested it with 2.5.30 version.
It is not solved.
With 2.5.16 version, there was work-arond for this problem.
If the search result is UTF-8 and if you change your web browser's encoding menu to UTF-8, then the files are committed with correct names. However with 2.5.30 version, although the default is UTF-8, and the encoding menu is set to as such, the committed result shows ---- in their names.
|
Sat 07 May 2005 07:11:52 AM UTC, comment #8:
To Su_blanc
Hi. Probably this bug is solved with 2.5.30 version. but I didn't test it.
Probably during this weekend I may be able to test it using 2.5.30 version.
To Sylvain LE
Hi. I don't know if the 2.5.30 version is stable enough yet. But I ran it for a few minutes, and I didn't find any anomaly.
But it is too short for good testing.
|
Fri 06 May 2005 06:58:30 AM UTC, comment #7:
I am using 2.5.28.1 version, so i cannot test. Please tell me when 2.5.30 series will be enough stable to be released.
|
Fri 06 May 2005 01:29:14 AM UTC, comment #6:
is this bug still actual in a 2.5.30-xx version?
|
Fri 04 Feb 2005 08:36:36 PM UTC, comment #5:
With the Mldk2.5.28m-Pmac version, when it commit the completed file, the file name becomes "------" where there were korean characters.
|
Thu 03 Feb 2005 05:31:37 AM UTC, comment #4:
It doesn't work with mlnet 2.5.28-pmac version which you can obtain from http://www.madk.com
|
Fri 31 Dec 2004 09:52:39 PM UTC, comment #3:
Hello, sprialvoice.
I couldn't compile the source code on my Mac.
As I said before the configure script fails in compiling.
|
Sat 30 Oct 2004 05:36:20 PM UTC, comment #2:
Hi. I'm sorry that I can't compile the mldonkey on my MacOS X machine.
When the configure script checks if my gcc can compile, it fails.
I have no problem with the gcc when I write my codes, though.
FYI, I use the mldonkey 2.5-16t version obtained from mldonkey forum for MacOS X. While it is searching intermediate result shows Korean characters well. But after finishing the search, and reloaing the page, all file names become some numbers.
Do you have a correct configure script for building on MacOS X?
|
Fri 29 Oct 2004 12:20:26 PM UTC, comment #1:
Please check if this bug still is in current CVS version.
You should find a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/
|
Mon 13 Sep 2004 12:26:01 AM UTC, original submission:
Although the current 2-5-24a version for MacOS X obtained from eDonkey forum for MacOS X, can search (semi) and download files with CJK file names, but it doesn't show the file names on the transfer page of the HTML UI, and can't change files names to their original name. MD hash numbers are still there as their file names.
This is very old bug.
|