On May  7 10:09, Chris J. Breisch wrote:
> Corinna Vinschen wrote:
> >And here's a problem which I'm not sure how to solve at all:
> >
> >When calling the latest mkpasswd, the primary group of the local
> >user account backing the Microsoft Account will *still* be "None".
> >
> >The reason is that the local account is just the same old account
> >as usual.  Its default primary group *is* "None".
> >
> >Only when logging in via the Micosoft Account email address, the
> >user token will not reflect what's stored in the local SAM, but
> >will have been changed by the OS as outlined in this thread.
> >
> >So, when a user decides to create a passwd file rather than using
> >the SAM/DB code in Cygwin, the information generated by mkpasswd
> >will not match the user token, and the primary group stored in
> >/etc/passwd will not even be available at all in the user token.
> >
> >I have not the faintest idea how to workaround this schizophrenia.
> >
> >
> >Corinna
> >
> Oh wow. It took me two reads of this to understand it. Caffeine is
> finally kicking in, I guess. Unless you just want to hard code the
> primary group that mkpasswd generates to "Users" for any account
> that it would tend to want to set as "None". That would be some
> smelly code though.

Hmm, but it might fix a couple of problems.  If we go ahead and
always convert the "None" primary group to "Users", we'd have a
pretty stable state, which works nicely for local accounts,
independently of habving logged in as normal account or as Microsoft 
Account.  This might be the easiest workaound, in fact.


Corinna

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