This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SegFault running "ls -l" after Microsoft Patch Day


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:


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


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 :-)


| 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]