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: 1.7.8-1 ls -l /proc/sys/Device causes system reset

On Mar  1 16:41, Tim Coalson wrote:
> > On 03/01/2011 04:57 PM, Tim Coalson wrote: > > The problem: > >  > > $ /bin/ls 
> >-l /proc/sys/Device > >  > > hit enter, and my system instantly reboots, without 
> >shutdown.  Without the -l  > > option, works fine.  Unfortunately, ls with 
> >colors enabled also causes this  > > behavior, even without -l, as in: > >  > > 
> >$ /bin/ls --color=auto /proc/sys/Device > That's because ls --color=auto enables 
> >stat() to know how to color> names, where omitting it relies on plain readdir() 
> >to just list the > name.  So it's obviously the act of stat()ing one of the 
> >devices in that > directory that is making windows upset.  Can you narrow it 
> >down to which > object, by trying things like 'ls --color=auto -d > 
> >/proc/sys/Device/[0-9]*' to limit to stat()ing just file names starting > with a 
> >digit, and so forth?  I couldn't reproduce your crash on my WinXP > system. 
> >
> Apologies for formatting, yahoo isn't subscribing to the list, so I'm faking the 
> formatting.
> I have found two culprits so far, SSHDRV65 and SSHDRV79.  They seem to be 
> drivers related to CD copy protection software in windows.

I *really* start to hate Windows XP.

But I can't reproduce this, neither on XP nor on W7.  Maybe because
I don't have these SSHDRVxx devices.

What puzzles me a bit is this:  The core of the functionality is in
a method called fhandler_procsys::exists().  This method is called
even for a simple ls which does not stat.  The underlying stat method
fhandler_procsys::fstat() also just calls the exists() method and then
fills the stat buffer.


There is one difference.  If exists() is called from fstat() then
there's an additional call to fetch the ACL from the device entry.
That's the only additional system call in this scenario.

Can you please test something for me?

Fetch the WinObj tool from sysinternals:

Install it and start it.  In WinObj, open the Device directory and
search for the SSHDRV65 and SSHDRV79 entries.  Right-click on them and
open the Properties dialog.  Then switch to the "Security" tab.
Does it work?  Does it show something useful or a kind of error message?


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

Problem reports:
Unsubscribe info:

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