This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: SegFault running "ls -l" after Microsoft Patch Day
- From: Dr Rainer Woitok <rainer dot woitok at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 15 Dec 2015 20:29:19 +0100
- Subject: Re: SegFault running "ls -l" after Microsoft Patch Day
- Authentication-results: sourceware.org; auth=none
- References: <20151214140532 dot GA29983 at calimero dot vinschen dot de>
Corinna,
On Monday, 2015-12-14 15:05:32 +0100, you wrote:
> ...
> > find: './System Volume Information': Permission denied
> > $
>
> This is normal if you don't run your shell elevated. Try again in an
> elevated shell.
Hm. I have several NTFS formatted USB sticks and a script which keeps
them up to date by -- among other things -- running a "find" command
against their mount points. Until Tuesday this script never complained
about a "./System Volume Information" directory, but since Wednesday it
does. If you are saying complaints regarding protected system files are
normal for an unprivileged Cygwin user, one of these patches must have
freshly created these directories on Wednesday when I plugged in the USB
sticks. At least the modification dates of the "./System Volume Inform-
ation/" directories on these USB sticks do not contradict this theory.
I'll try to remove these directories on the USB sticks as soon as this
issue is solved somehow.
But I'm still not able to issue a normal "ls -l /C" command, regardless
of whether or not I'm running from an elevated shell. Well, at least so
I thought. While providing evidence for this by running the commands
ls -ld /C/PerfLogs
ls -ld /C/MSOCache
ls -ld /C/Config.Msi
ls -ld /C/System\ Volume\ Information/
ls -l /C
from both, a privileged and an unprivileged shell, I found that all five
commands produce segmentation faults in the unprivileged shell, but that
only the last command produces a segmentation fault in the privileged
shell, while the other commands succeed. Since my "/etc/passwd" file
uses more Unix like names even for the typical Windows accounts, I then
ran these commands with an additional "-n" option to produce less con-
fusing listings, ... and low and behold, now all five commands succeed-
ed in BOTH, the privileged and the unprivileged shell!
I then inspected my "/etc/passwd" file and removed the last line from
it, which I had added long ago to fight the "Unknown+User" and "Unknown+
Group" entries in the "ls -l" output:
other:*:4294967295:4294967295:::
Now all five commands above succeed for the privileged user (though with
an ouput cluttered with "Unknown+*" entries :-), and at least the normal
"ls -l /C" command now also succeeds for the unprivileged user, while
the other four "ls -ld" commands are still segfaulting. Finally, I also
removed the corresponding line
other:*:4294967295:
from my "/etc/group" file and -- you guessed it -- now everything works
in both, elevated and normal shell. Sigh.
What is still missing is some sort of explanation. How can a Windows
patch cause these two lines in files "/etc/passwd" and "/etc/group" to
fail working, and why is the effect different, depending on privilege
status? (Remember: I first applied Windows patches, then I ran into
problems, and finally I updated Cygwin).
> ...
> > $ ls -lF /C
> > Segmentation fault (core dumped)
> > $
>
> I can't reproduce this one.
Perhaps you can now with this additional information :-)
Sincerely,
Rainer
----------------------------------------------------------------------
| Rainer M Woitok | Phone : (+49 60 93) 487 95 95 |
| Kolpingstraße 3 | Mobile: (+49 172) 813 6 831 |
| D-63846 Laufach | Mail : Rainer.Woitok@Gmail.Com |
| Germany | |
----------------------------------------------------------------------
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple