Mail Archives: cygwin/2003/06/05/12:54:27
On Thu, 5 Jun 2003, Pavel Tsekov wrote:
> On Thu, 5 Jun 2003, Igor Pechtchanski wrote:
>
> [snip]
>
> > Okay, Ronald, you're suffering from the UID wrapping problem. Cygwin UIDs
> > are currently 16 bit, so any number higher than 65535 will get wrapped
> > (and did). You can change your UID to any unique number smaller than
> > 65535 (56297 should do as well as any other). I don't know that that's
> > the cause of your mc problem, but it's something to fix nonetheless.
> >
> > If it turns out to fix your problem, it's a bug in 'mc', IMO.
>
> See this code:
>
> current_user_uid = getuid ();
> pwd = getpwuid (current_user_uid);
> g_return_if_fail (pwd != NULL);
>
> It may be regarded as a bug too - but the fact that an assertion is shown
> means that the author of the code decided that it is the right thing to
> do i.e. it is not a programmering bug. Obiviosly the auhtor thought for
> a while and decided that having UID for which a corresponding passwd
> struct cannot be retrieved is not a normal situation.
>
> I cannot judge if he was right or not without further inspecting the code -
> this particular situation maybe can be avoided by removing the offending
> call because there is this comment at its start:
>
> /* This function initialize global GTree with the gids of groups,
> to which user belongs. Tree also store corresponding string
> with the name of the group.
> FIXME: Do we need this names at all? If not, we can simplify
> initialization by eliminating g_strdup's.
> */
>
> I have investigate to draw a conclusion though. But then there may be
> other places where getpwuid() is called the same way - this means a lot of
> work have to be put into finding the places and dealing with each one.
> I don't think that I need to do all this now when 64 bit Cygwin is
> to be released.
>
> Anyway if you see a clean solution to this problem, one that won't
> impact the functionality of the program, I'll be happy to follow any
> advice you can give and release an update.
>
> Pavel
Pavel,
This may be a Cygwin-specific problem. On Cygwin, /etc/passwd doesn't
play as key a role as it does on other Unix systems (e.g., it's not
required for logging in on the console). Thus, it's quite possible that
someone will attempt to run other applications when missing /etc/passwd
entries, and what is an abnormal situation on Unix systems might be simply
an annoying omission in Cygwin. I don't think the assert/crash is
justified in this case. At the very least it should have a more
informative error message, and a better solution would be to simply remove
the assert and conditionalize the following code on (pwd != NULL)
(possibly with #ifdef __CYGWIN__ around it, although I don't think it'll
affect the other Unix systems all that much). I'm not all that familiar
with mc, so the usual disclaimers apply to the above.
Igor
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`' -. ;-;;,_ igor AT watson DOT ibm DOT com
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster." -- Patrick Naughton
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -