bugmldonkey, a multi-networks file-sharing client - Bugs: bug #12910, File name after commiting is...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #12910: File name after commiting is changed to someting like "______________________"

Submitter:  None
Submitted:  Fri 29 Apr 2005 10:12:51 PM UTC
   
 
Category:  Core Severity:  3 - Normal
Item Group:  Program malfunction Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2.5.30.15 Release: 
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86

Jump to the original submission

Wed 12 Oct 2005 09:53:31 PM UTC, comment #39: 

@ Kargor
LC_CTYPE and LANG (generally in etc/environment) are maybe well defined in your system but it is not enough.
make sure the locales (at least the one you use) are existing and have been built.
output of the command 'locale'?
I ever run mldonkey on windows and linux and I never encountered any problem.

su_blanc <su_blanc>
Group Member
Wed 12 Oct 2005 04:16:08 PM UTC, comment #38: 

For me, I can't try 2.6.4. I obtained a prebuilt version, and it is linked to a specific version of a library. The library doesn't exist on the MacOS X Tiger.
So, I couldn't test it. I'm sorry.

JongAm Park <JongAm>
Wed 12 Oct 2005 02:57:32 PM UTC, comment #37: 

I never got mldonkey 2.6.4 to work (on a Linux box), no matter how I set the various environment variables suggested in this thread.

So I decided to take a shortcut by just applying the "Mac" patch suggested a few posts below --- so now I'm back at where I was before: getting correct filenames instead of _________.

So, if the env-variables don't work, a recompile can fix it.

Would be better to fix this for good, but well... it's working now, and it's not my software :-)

Btw... this has made it into my top-10: I've seen quite a few unix programs with various 8-bit char problems, but I've never seen one that couldn't even handle the ASCII chars (letters, digits, ...) without special patches/configuration.

Kargor <kargor>
Tue 04 Oct 2005 07:53:43 AM UTC, comment #36: 

I have similar problem. But no matter what I changed the LC_CTYPE to, the language and locale showed is always "EN" and "ANSI_X3.4-1968". Why?

I've tried 2.5.30-16 and 2.6.4.

Anonymous
Fri 08 Jul 2005 04:20:03 AM UTC, comment #35: 

This problem is solved!!!!

Thank you.

JongAm Park <JongAm>
Thu 07 Jul 2005 02:26:25 AM UTC, comment #34: 

OK. Now I tested with the 2.5.30.17 version.

It recognizes the language as KO and the locale as UTF-8.

Let's wait and see what the completed file names become.

Thank you for this wonderful work!

JongAm Park <JongAm>
Thu 07 Jul 2005 02:13:49 AM UTC, comment #33: 

Oh.. I tested with 2.5.30.16.

Let me try with the 17 version.

JongAm Park <JongAm>
Wed 06 Jul 2005 11:27:52 AM UTC, comment #32: 

@JongAm Park: Are you using a current 2.5.30.17 core for your tests?
The bugfix by su_blanc was committed in that version.

spiralvoice <spiralvoice>
Group administrator
Wed 06 Jul 2005 01:41:27 AM UTC, comment #31: 

Hello, Su Blanc.

Oh! I see. I missed the line.

Even though I change the LC_CTYPE, the current language detected by mlnet is "EN" still.

Here is the dump.

JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ export LC_CTYPE="ko_KR.UTF-8"
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="ko_KR.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8/ko_KR.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8"
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ ./mlnet
Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN



JongAm Park <JongAm>
Wed 06 Jul 2005 12:48:14 AM UTC, comment #30: 

@JongAm Park

you didn't get me.
LC_CTYPE should change *ONLY* the LANGUAGE ('EN', 'KO', ...) detected by mlnet *NOT* the CODESET ('US-ASCII', 'UTF-8', ...).
Thus if you change LC_CTYPE, does the current LANGUAGE detected by melnet changed from 'EN' to 'KO'?

For the CODESET we have to patch the source src/utils/lib/charsetstubs.c, thus mlnet will detect 'UTF-8' by default on MACOS.

value
ml_locale_charset(void)
{

  const char *str;

  #ifdef MACOS
    str = "UTF-8";
  #else
    #ifdef HAVE_LOCALE_CHARSET
      str = locale_charset ();
    #else
      setlocale(LC_CTYPE, "");
      str = nl_langinfo(CODESET);
    #endif /* HAVE_LOCALE_CHARSET */
  #endif /* MACOS */

  if (!str)
    raise_error ();

  return (copy_string ((char*) str));
}

su_blanc <su_blanc>
Group Member
Tue 05 Jul 2005 01:22:16 AM UTC, comment #29: 

Hello, Su Blanc.

I tried changing the LC_CTYPE explicitely.

However, the mlnet still think it is US-ASCII.

JongAm Park <JongAm>
Tue 05 Jul 2005 12:35:46 AM UTC, comment #28: 

Hello, Su Blanc~

Actually I didn't change the LC_CTYPE only.

I changed the LC_ALL, so, if you type "locale", you can also check the LC_CTYPE is changed as such.

So, in my case, although they are set to ko_KR.UTF-8, the mlnet still thinks it is US-ASCII

JongAm Park <JongAm>
Mon 04 Jul 2005 01:00:01 AM UTC, comment #27: 

sorry i wasn't logged in.
no the question is : if you change LC_CTYPE to "ko_KR.UTF-8", does the LANGUAGE detected by mlnet change to "KR"?
the CODESET is anyway not detected properly

su_blanc <su_blanc>
Group Member
Sat 02 Jul 2005 07:47:17 AM UTC, comment #26: 

Hi, None.. I'm sorry to call you NONE, because there is no name on "posted by" column.

Anyway, whatever locale I change to, it is still US-ASCII.
Actually, LC* types can be changed properly, but mlnet still thinks that it is US-ASCII.

I already tested the ko_KR.UTF-8 case.

Thank you.

JongAm Park <JongAm>
Sat 02 Jul 2005 07:19:52 AM UTC, comment #25: 

@JongAm Park

1) Can you change the LC_CTYPE environment variable to "ko_KR.UTF-8" and see if the output of mlnet gives "...Current language of the target machine is KR ..."

2) i think this core uses the nl_langinfo but not the locale_charset () from libcharset...
There is a report stating that nl_langinfo(CODESET) returns "US-ASCII" on mac in the case the environment variables LANG, LC_CTYPE, LC_ALL are not set by the system.
http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg00048.html

but mlnet works well.
otherwise we would fall back to the string "ASCII" but not to "US-ASCII".

@spiralvoice and amorphous

The language detected by mlnet is given by LC_CTYPE that is the category related to encodings as per definition of a LOCALE model.
Maybe we should change ml_get_default_language by testing LANG first, then LC_ALL and then only LC_TYPE for all platforms?

For MacOS X, we should modify ml_locale_charset.
There is this paper from Bruno Haible (Author of the GNU libiconv) http://www.caddr.com/macho/archives/sbcl-devel/2004-11/4221.html
As suggested, on MacOS X, the default encoding UTF-8 has to be supposed.
Or instead of nl_langinfo on MacOS X, we could try to catch LANG, LC_ALL with getenv before to fallback to "UTF-8".

Anonymous
Fri 01 Jul 2005 07:06:16 AM UTC, comment #24: 

Hello.

I set the LANG environment variable again.

JongAm-Parks-Computer:/etc jongampark$ locale
LANG="ko_KR.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
JongAm-Parks-Computer:/etc jongampark$ export LANGUAGE=ko_KR.UTF-8
JongAm-Parks-Computer:/etc jongampark$ locale
LANG="ko_KR.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
JongAm-Parks-Computer:/etc jongampark$ cd /Applications/Network/Mldk2.5.30/
JongAm-Parks-Computer:/Applications/Network/Mldk2.5.30 jongampark$ ./mlnet
Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN


However it still treat the locale as US-ASCII.

Can someone advise me how to set the locale properly?

JongAm Park <JongAm>
Fri 01 Jul 2005 06:26:24 AM UTC, comment #23: 

To sprialvoice

Well.. The Mac OS X system uses UTF-8 for its file system level.

I also set LANG environment variable to UTF-8 in terminal.
However the launched mlnet still recognize its encoding as US-ASCII.

To Su_Blanc
Well, yes. With the Finder, I can write in languages other than English. In its Terminal program, I also can write file names that way.


JongAm Park <JongAm>
Thu 30 Jun 2005 12:18:05 PM UTC, comment #22: 

"Current locale of the target machine is US-ASCII"

You have to have UTF-8 or something similar here, otherwise
MLDonkey converts all non-US-ASCII characters to US-ASCII,
the system has to provide UTF support, otherwise MLDonkey will
circumvent using non-available characters by replacing them with "_".

Please see my comments 14-17 how I managed to use UTF characters
with MLDonkey on a system which normally lacks UTF support.
It is possible, however the FTP and SSH daemons from that system
(outside the chroot) can´t access those files;-) But thats another
story, I have to compile some daemons for use in that chroot so
it will work.

If the core does not start with this message:
"Current locale of the target machine is UTF-8 "
it will never work for you.

spiralvoice <spiralvoice>
Group administrator
Thu 30 Jun 2005 09:08:09 AM UTC, comment #21: 

Can you write manually files with names having those characters that are replaced by mlnet in '_' on your system ?

su_blanc <su_blanc>
Group Member
Thu 30 Jun 2005 04:16:48 AM UTC, comment #20: 

Hi.

It is US-ASCII.

Here is the dump of the screen.

Hope it helps.

Blocking system signals until core is started...
Current locale of the target machine is US-ASCII
Current language of the target machine is EN
List of charmap used to convert the strings:
  Use encoding CP1252
  Use encoding ISO-8859-15
  Use encoding 850
  Use encoding CP819
  Use encoding MAC
  Use encoding 437
  Use encoding 860
  Use encoding 863
  Use encoding ANSI_X3.4-1968
  Use encoding C99
  Use encoding ISO-10646-UCS-2
  Use encoding UCS-2BE
  Use encoding UCS-2LE
  Use encoding ISO-10646-UCS-4
  Use encoding UCS-4BE
  Use encoding UCS-4LE
  Use encoding UTF-16
  Use encoding UTF-16BE
  Use encoding UTF-16LE
  Use encoding UTF-32
  Use encoding UTF-32BE
  Use encoding UTF-32LE
  Use encoding UNICODE-1-1-UTF-7
  Use encoding UCS-2-INTERNAL
  Use encoding UCS-2-SWAPPED
  Use encoding UCS-4-INTERNAL
  Use encoding UCS-4-SWAPPED

JongAm Park <JongAm>
Thu 30 Jun 2005 01:00:48 AM UTC, comment #19: 

@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 '_'?

su_blanc <su_blanc>
Group Member
Wed 29 Jun 2005 03:41:18 AM UTC, comment #18: 

OK. I tested it.

The file names are still ----- where the characters are not English.

JongAm Park <JongAm>
Sat 25 Jun 2005 11:05:21 PM UTC, comment #17: 

As users can circumvent this through correctly setting up their
systems and there is currently no better idea doing this can this
bug be closed?

spiralvoice <spiralvoice>
Group administrator
Sun 22 May 2005 03:10:18 AM UTC, comment #16: 

Ok, can answer my question myself for Debian:
/usr/lib/locale/locale-archive

copying it into my chroot solves my problem:

# export LANG=de_DE.utf8
# export LANGUAGE=de_DE.utf8
# chroot /disk/mlnet /mlnet -stdout
Current locale of the target machine is UTF-8
Current language of the target machine is DE
List of charmap used to convert the strings:
  Use encoding CP1252
  Use encoding ISO-8859-15
  Use encoding 850
  Use encoding CP819
  Use encoding MAC
  Use encoding 437
  Use encoding 860
  Use encoding 863
  Use encoding ANSI_X3.4-1968
  Use encoding C99
  Use encoding ISO-10646-UCS-2
  Use encoding UCS-2BE
  Use encoding UCS-2LE
  Use encoding ISO-10646-UCS-4
  Use encoding UCS-4BE
  Use encoding UCS-4LE
  Use encoding UTF-16
  Use encoding UTF-16BE
  Use encoding UTF-16LE
  Use encoding UTF-32
  Use encoding UTF-32BE
  Use encoding UTF-32LE
  Use encoding UNICODE-1-1-UTF-7
  Use encoding UCS-2-INTERNAL
  Use encoding UCS-2-SWAPPED
  Use encoding UCS-4-INTERNAL
  Use encoding UCS-4-SWAPPED

spiralvoice <spiralvoice>
Group administrator
Sat 21 May 2005 11:16:36 AM UTC, comment #15: 

My core prints this:

# ./mlnet -stdout
Current locale of the target machine is ANSI_X3.4-1968
Current language of the target machine is EN
List of charmap used to convert the strings:
  Use encoding CP1252
  Use encoding ISO-8859-15
  Use encoding 850
  Use encoding CP819
  Use encoding MAC
  Use encoding 437
  Use encoding 860
  Use encoding 863
  Use encoding ANSI_X3.4-1968
  Use encoding C99
  Use encoding ISO-10646-UCS-2
  Use encoding UCS-2BE
  Use encoding UCS-2LE
  Use encoding ISO-10646-UCS-4
  Use encoding UCS-4BE
  Use encoding UCS-4LE
  Use encoding UTF-16
  Use encoding UTF-16BE
  Use encoding UTF-16LE
  Use encoding UTF-32
  Use encoding UTF-32BE
  Use encoding UTF-32LE
  Use encoding UNICODE-1-1-UTF-7
  Use encoding UCS-2-INTERNAL
  Use encoding UCS-2-SWAPPED
  Use encoding UCS-4-INTERNAL
  Use encoding UCS-4-SWAPPED

spiralvoice <spiralvoice>
Group administrator
Sat 21 May 2005 11:14:24 AM UTC, comment #14: 

I am using MLDonkey chroot´ed with glibc 2.3 in the chroot on a
system which lacks glibc completely. Which files do I have to copy
into my chroot to have UTF-8 support there?
As written in bug #9101 I can use UTF-8 files without problems
but I have the same situation described in this bug. I know its
not really a bug, its a feature.
But maybe some LANG files can help me?

spiralvoice <spiralvoice>
Group administrator
Sat 21 May 2005 03:31:13 AM UTC, comment #13: 

mlnet cannot write a [CJK] string if your locale is ISO-8859-15 (considered as western european by mlnet).
so each character contained in the string, that are not compatible with your locale, will be replaced by '_'.
I did it like this for a safe implementation and make sure we can commit all the files.
I'm opened to any suggestion that could improve/enhance the way we commit the file with its name.

su_blanc <su_blanc>
Group Member
Fri 20 May 2005 04:53:18 PM UTC, comment #12: 

What happens if the files' names are in language X, but your locale is for language Y?

JongAm Park <JongAm>
Thu 19 May 2005 05:31:16 PM UTC, comment #11: 

Your versions are working fine for me on eisfair! Look here: http://www.mldonkey.org/phpbb2/viewtopic.php?p=31432

So if you could compile a version with this patch, I will test it as fast as possible.

Anonymous
Thu 19 May 2005 05:23:57 PM UTC, comment #10: 

Ask here (http://www.matze-b.dyndns.org/) if he can make 2.5.30.15 cores for EISFAIR.

spiralvoice <spiralvoice>
Group administrator
Thu 19 May 2005 04:54:07 PM UTC, comment #9: 

Believe me, I would test it if I'm able to compile the files! :( I don't know how to do and I think my Eisfair isn't able to do it either. Sorry!
If you make a binary for me, I will test it (and try to set my locale back to Posix instead auf C) of course!

Anonymous
Thu 19 May 2005 04:07:16 PM UTC, comment #8: 

Please test current CVS + patch #3984.
Do you compile yourself?

spiralvoice <spiralvoice>
Group administrator
Tue 03 May 2005 03:03:00 AM UTC, comment #7: 

you may try to set your environment variable LANG to "de_DE".
POSIX is very restrictive (like C).

su_blanc <su_blanc>
Group Member
Mon 02 May 2005 11:39:35 PM UTC, comment #6: 

I don't know why, but now it works fine!
I have restarted the core after it freezes and now it has created three files with the right name. But I will investigate this further!

Stefan Bassing <stickedy>
Mon 02 May 2005 01:03:54 PM UTC, comment #5: 

OK, so here is my output:
LANG=POSIX
LC_CTYPE=de_DE@euro
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

Does this help?

Stefan Bassing <stickedy>
Mon 02 May 2005 08:55:59 AM UTC, comment #4: 

you can try the command 'locale' in a console. see 'man locale' for further infos...

su_blanc <su_blanc>
Group Member
Mon 02 May 2005 05:55:55 AM UTC, comment #3: 

How or where can I find out how my LOCALE is set? I didn't find anything about this.
The file extension is not properly written!

Stefan Bassing <stickedy>
Mon 02 May 2005 02:21:49 AM UTC, comment #2: 

That's correct. The number of "_" is according to the number of chars seen by Ocaml (may differ from the real number further to the encoding used).
The core is unable to convert the file name into a string as per your LOCALE param. How is set your LOCALE?
It is most likely your params (LANG & LOCALE) are not properly set or those params are too restrective to allow a proper conversion from the chars used in your file names.
Is the extension of the file properly written. Something like "________.png" or "________.ogg"?

su_blanc <su_blanc>
Group Member
Fri 29 Apr 2005 10:25:22 PM UTC, comment #1: 

When a file is downloaded and commited, the file name in the incoming directory is changed to something like "______________________". The number of the "_" is variable and different each time. I think it is as long as the original file name, but I can't verify this right now.
The content of the file is OK and it is working when I manually rename the file.
Seems like some kind of character conversion error or something like that to me.

Stefan Bassing <stickedy>
Fri 29 Apr 2005 10:12:51 PM UTC, original submission:  


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-07-08 spiralvoice Open/ClosedOpen Closed
2005-07-08 spiralvoice StatusWont Fix Fixed
2005-05-21 spiralvoice StatusNone Wont Fix
    Release2.5.30.14 2.5.30.15

Back to the top

Powered by Savane 3.13-4448.
Corresponding source code