Re: New passwd/group handling in Cygwin - test results and observations

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]

On Feb 16 17:52, Andrey Repin wrote:
> 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.

No, it's the local group with the RID 513, which exists on *all*
machines, but is invisible, unless you call NetUserEnum, which
enumerates it, or you call NetUserGetInfo with the localized name.

This group is called "None" in the english OS versions, "Kein" in
the german version, "Aucun" in the french version, etc.  All local
users accounts have this group invariably set as their primary group.

For some reason Microsoft decided ages ago, that this group does
not show up in the GUI, and that it's not possible to change the primary
group outside of domains.  Why that is, I have no idea.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]