Greetings, Corinna Vinschen! >> > But this is a problem not different from Linux. If you have a username >> > with non-ASCII chars, it will use *some* encoding in the passwd DB, >> > usually UTF-8 these days. If you then change the codeset in your >> > application, you will still get your username in UTF-8. It won't be >> > changed on the fly, just because your application calls setlocale. >> >> I understand it (mostly), but there's actually two issues, not one. >> One issue is the display part, where names are output for user consumption. >> Another can be observed in, i.e., rsync, and file access in general (remember >> the discussion about accessing long directory names in unicode). >> Changing LANG variable DO matter for the latter, and you may only hope that >> whatever is output in the former case is actually printable (thank God, most >> of the time it actually is, in case of UTF-8). >> It is getting even more complicated, when you consider the fact, that in >> Windows you have 2 different single-byte encodings, so-called ANSI (for GUI >> applications) and OEM (for console). And alot of stuff making assumptions >> without consulting with current status of things. >> As convoluted the problem is, I think, we need some sort of solution, or at >> the very least - documentation.
> Sorry, I can't provide an easy solution, and afaik this is documented. I don't know, how it did not hit my head earlier, but now that I think about it... The fact `ls' does not print correct group names, but correctly translate dates... eww, wait. There's something bad happens under the hood. Please check this image: http://img513.imageshack.us/img513/43/jn7n.png LANG is set (pre-set, before Cygwin tree start) to ru_RU.UTF-8 for mintty and ru_RU.CP866 for console. As you can see, existing group (i.e. - "Administrators") is properly translated to chosen locale, which is not the case for group "Отсутствует". The SID of the group "DAEMON2\Отсутствует" is S-1-5-21-1801674531-1644491937-1606980848-513 Cygwin show it as -rwxr-xr-x 1 197612 197121 45597 мар 22 2013 xargs.exe which matching your description for "Accounts from the local machine's user DB (SAM)" (0x30000+513 =197121) (and yes, the leading part of the SID is matching the one of the other users on this system), but the group is missing from `wmic GROUP LIST' output. I presume, it was deleted at one point, or it is remnants of the previous OS installation, transferred over with the disk to this system. Either case explains the name of the group - "Missing" or "Nonexistent". Means, it's name does not exist in current SAM database. -- WBR, Andrey Repin (anrdae...@yandex.ru) 14.02.2014, <21:19> Sorry for my terrible english...
