System reboot (udfs.sys), cygwin 1.7

System reboot (udfs.sys), cygwin 1.7

[Gregory C. Sharp]

I'm testing out cygwin 1.7, and ran into a problem.  I run a small
script which checksums my dvd+r backups, something like this:

find -L /cygdrive/d -noleaf -type f -exec cksum {} \;

I try it out on cygwin 1.7, and 3 out of 4 times I get a system
panic and reboot.  Dumpchk/WinDBG reveal access violation in udfs.sys.
This has never happened when I run the script on cygwin 1.5.
Stacktrace as follows:

ChildEBP RetAddr  Args to Child
f683fd78 804eeb49 88768288 00000000 00000000 udfs!0xbb7db225
f683fda8 8052e8c2 88768288 00000000 00000000 ntkrnlmp!ExQueueWorkItem+0x167
f683fddc 80543966 804eea9a 00000000 00000000 
ntkrnlmp!PsSetCreateThreadNotifyRoutine+0xa8
00000000 00000000 00000000 00000000 00000000 
ntkrnlmp!KiDispatchInterrupt+0x516

System details: Windows 2000 SP4 fully patched, Pentium IV CPU
(hyperthreaded), UDFS.SYS 5.0.2195.7006 (Dec 2, 2004), Samsung
DVD ROM SD-616T, DVD+R media, Japanese locale (CP932).

Any ideas what is going on?

-- 
Gregory C. Sharp
Dept. of Radiation Oncology
Massachusetts General Hospital
gcsharp@partners.org  /  617-724-3866
http://gray.mgh.harvard.edu


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.


--
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/

Re: System reboot (udfs.sys), cygwin 1.7

[Larry Hall (Cygwin)]

Gregory C. Sharp wrote:
> 
> I'm testing out cygwin 1.7, and ran into a problem.  I run a small
> script which checksums my dvd+r backups, something like this:
> 
> find -L /cygdrive/d -noleaf -type f -exec cksum {} \;
> 
> I try it out on cygwin 1.7, and 3 out of 4 times I get a system
> panic and reboot.  Dumpchk/WinDBG reveal access violation in udfs.sys.
> This has never happened when I run the script on cygwin 1.5.
> Stacktrace as follows:
> 
> ChildEBP RetAddr  Args to Child
> f683fd78 804eeb49 88768288 00000000 00000000 udfs!0xbb7db225
> f683fda8 8052e8c2 88768288 00000000 00000000 ntkrnlmp!ExQueueWorkItem+0x167
> f683fddc 80543966 804eea9a 00000000 00000000 
> ntkrnlmp!PsSetCreateThreadNotifyRoutine+0xa8
> 00000000 00000000 00000000 00000000 00000000 
> ntkrnlmp!KiDispatchInterrupt+0x516
> 
> System details: Windows 2000 SP4 fully patched, Pentium IV CPU
> (hyperthreaded), UDFS.SYS 5.0.2195.7006 (Dec 2, 2004), Samsung
> DVD ROM SD-616T, DVD+R media, Japanese locale (CP932).
> 
> Any ideas what is going on?

Yes.  There's a bug in your UDFS driver.  Since it is rather old, your
best bet is to check to see if there's an update.  Otherwise, report the
bug to your provider.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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/

Re: [1.7] System reboot (udfs.sys), cygwin 1.7

[Christopher Faylor]

On Tue, Dec 30, 2008 at 11:25:43AM -0500, Gregory C. Sharp wrote:
>I'm testing out cygwin 1.7, and ran into a problem.  I run a small
>script which checksums my dvd+r backups, something like this:
>
>find -L /cygdrive/d -noleaf -type f -exec cksum {} \;
>
>I try it out on cygwin 1.7, and 3 out of 4 times I get a system panic
>and reboot.  Dumpchk/WinDBG reveal access violation in udfs.sys.  This
>has never happened when I run the script on cygwin 1.5.  Stacktrace as
>follows:
>
>ChildEBP RetAddr Args to Child f683fd78 804eeb49 88768288 00000000
>00000000 udfs!0xbb7db225 f683fda8 8052e8c2 88768288 00000000 00000000
>ntkrnlmp!ExQueueWorkItem+0x167 f683fddc 80543966 804eea9a 00000000
>00000000 ntkrnlmp!PsSetCreateThreadNotifyRoutine+0xa8 00000000 00000000
>00000000 00000000 00000000 ntkrnlmp!KiDispatchInterrupt+0x516
>
>System details: Windows 2000 SP4 fully patched, Pentium IV CPU
>(hyperthreaded), UDFS.SYS 5.0.2195.7006 (Dec 2, 2004), Samsung DVD ROM
>SD-616T, DVD+R media, Japanese locale (CP932).
>
>Any ideas what is going on?

We need the information here:

http://cygwin.com/problems.html

Also, if you can get an strace of the failure that would probably be
helpful.  It may be too big to send to the list, though.  If so, please
let me know here and I'll arrange for a place for you to upload it.

cgf

--
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/

Re: [1.7] System reboot (udfs.sys), cygwin 1.7

[Christopher Faylor]

On Tue, Dec 30, 2008 at 12:06:38PM -0500, Christopher Faylor wrote:
>On Tue, Dec 30, 2008 at 11:25:43AM -0500, Gregory C. Sharp wrote:
>>I'm testing out cygwin 1.7, and ran into a problem.  I run a small
>>script which checksums my dvd+r backups, something like this:
>>
>>find -L /cygdrive/d -noleaf -type f -exec cksum {} \;
>>
>>I try it out on cygwin 1.7, and 3 out of 4 times I get a system panic
>>and reboot.  Dumpchk/WinDBG reveal access violation in udfs.sys.  This
>>has never happened when I run the script on cygwin 1.5.  Stacktrace as
>>follows:
>>
>>ChildEBP RetAddr Args to Child f683fd78 804eeb49 88768288 00000000
>>00000000 udfs!0xbb7db225 f683fda8 8052e8c2 88768288 00000000 00000000
>>ntkrnlmp!ExQueueWorkItem+0x167 f683fddc 80543966 804eea9a 00000000
>>00000000 ntkrnlmp!PsSetCreateThreadNotifyRoutine+0xa8 00000000 00000000
>>00000000 00000000 00000000 ntkrnlmp!KiDispatchInterrupt+0x516
>>
>>System details: Windows 2000 SP4 fully patched, Pentium IV CPU
>>(hyperthreaded), UDFS.SYS 5.0.2195.7006 (Dec 2, 2004), Samsung DVD ROM
>>SD-616T, DVD+R media, Japanese locale (CP932).
>>
>>Any ideas what is going on?
>
>We need the information here:
>
>http://cygwin.com/problems.html
>
>Also, if you can get an strace of the failure that would probably be
>helpful.  It may be too big to send to the list, though.  If so, please
>let me know here and I'll arrange for a place for you to upload it.

I got a system reboot (once) from this too.  How wonderful is that?

It seemed to die following a symlink in my dev directory.  Investigating
now.

cgf

--
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/

Re: [1.7] System reboot (udfs.sys), cygwin 1.7 (question for Eric Blake)

[Christopher Faylor]

On Tue, Dec 30, 2008 at 12:41:04PM -0500, Christopher Faylor wrote:
>On Tue, Dec 30, 2008 at 12:06:38PM -0500, Christopher Faylor wrote:
>>On Tue, Dec 30, 2008 at 11:25:43AM -0500, Gregory C. Sharp wrote:
>>>I'm testing out cygwin 1.7, and ran into a problem.  I run a small
>>>script which checksums my dvd+r backups, something like this:
>>>
>>>find -L /cygdrive/d -noleaf -type f -exec cksum {} \;
>>>
>>>I try it out on cygwin 1.7, and 3 out of 4 times I get a system panic
>>>and reboot.  Dumpchk/WinDBG reveal access violation in udfs.sys.  This
>>>has never happened when I run the script on cygwin 1.5.  Stacktrace as
>>>follows:
>>>
>>>ChildEBP RetAddr Args to Child f683fd78 804eeb49 88768288 00000000
>>>00000000 udfs!0xbb7db225 f683fda8 8052e8c2 88768288 00000000 00000000
>>>ntkrnlmp!ExQueueWorkItem+0x167 f683fddc 80543966 804eea9a 00000000
>>>00000000 ntkrnlmp!PsSetCreateThreadNotifyRoutine+0xa8 00000000 00000000
>>>00000000 00000000 00000000 ntkrnlmp!KiDispatchInterrupt+0x516
>>>
>>>System details: Windows 2000 SP4 fully patched, Pentium IV CPU
>>>(hyperthreaded), UDFS.SYS 5.0.2195.7006 (Dec 2, 2004), Samsung DVD ROM
>>>SD-616T, DVD+R media, Japanese locale (CP932).
>>>
>>>Any ideas what is going on?
>>
>>We need the information here:
>>
>>http://cygwin.com/problems.html
>>
>>Also, if you can get an strace of the failure that would probably be
>>helpful.  It may be too big to send to the list, though.  If so, please
>>let me know here and I'll arrange for a place for you to upload it.
>
>I got a system reboot (once) from this too.  How wonderful is that?
>
>It seemed to die following a symlink in my dev directory.  Investigating
>now.

Hmm.  After removing the /dev/fd directory that I had created years
ago, find now just SEGVs.  And, it seems to be dying in find itself
if the stack dump is any indication.

Eric, is there any way that you could confirm or deny this?  I would
rather not build a debugging version of find if I don't have to.

cgf

--
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/

find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Christopher Faylor]

On Tue, Dec 30, 2008 at 12:52:46PM -0500, Christopher Faylor wrote:
>Hmm.  After removing the /dev/fd directory that I had created years
>ago, find now just SEGVs.  And, it seems to be dying in find itself
>if the stack dump is any indication.
>
>Eric, is there any way that you could confirm or deny this?  I would
>rather not build a debugging version of find if I don't have to.

It was stupid of me to assume that this was just a generic find problem.
If I'd actually checked the error log I would have seen this:

assertion "state.type != 0" failed: file "/usr/src/findutils-4.5.3-1/src/findutils-4.5.3/find/ftsfind.c", line 475, function: consider_visiting

This is apparently caused by a symlink that looks like this:

lrwxrwxrwx  1 cgf None       6 Jul  9  2005 n -> //none

I don't remember creating that symlink.  Apparently I was checking on
creating symlinks to nonexistent domains back in 2005.

I don't know if this is a find bug or a cygwin bug.  I could see it
being either or both.

cgf

--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Corinna Vinschen]

On Dec 30 14:06, Christopher Faylor wrote:
> On Tue, Dec 30, 2008 at 12:52:46PM -0500, Christopher Faylor wrote:
> >Hmm.  After removing the /dev/fd directory that I had created years
> >ago, find now just SEGVs.  And, it seems to be dying in find itself
> >if the stack dump is any indication.
> >
> >Eric, is there any way that you could confirm or deny this?  I would
> >rather not build a debugging version of find if I don't have to.
> 
> It was stupid of me to assume that this was just a generic find problem.
> If I'd actually checked the error log I would have seen this:
> 
> assertion "state.type != 0" failed: file "/usr/src/findutils-4.5.3-1/src/findutils-4.5.3/find/ftsfind.c", line 475, function: consider_visiting
> 
> This is apparently caused by a symlink that looks like this:
> 
> lrwxrwxrwx  1 cgf None       6 Jul  9  2005 n -> //none
> 
> I don't remember creating that symlink.  Apparently I was checking on
> creating symlinks to nonexistent domains back in 2005.
> 
> I don't know if this is a find bug or a cygwin bug.  I could see it
> being either or both.

It looks like a find bug to me.

The assertion is basically

  if (ent->fts_info == FTS_NSOK || ent->fts_info == FTS_NS)
    assert (state.type != 0);

state.type is set in the calling function find() like this:

  while ( (ent=fts_read(p)) != NULL )
    {
      state.have_type = !!ent->fts_statp->st_mode;
      state.type = state.have_type ? ent->fts_statp->st_mode : 0;
    }

which is a bug, AFAICS.  The reason is that per the fts_read man page
the value of ent->fts_statp is undefined if ent->fts_info is FTS_NSOK
or FTS_NS.  So the values of state.have_type and consequentially
state.type are undefined as well and the above assertion makes no sense.

Additionally, consider that the BSD variant of fts_read as used by Cygwin
memset's fts_statp to 0 in the FTS_NS case.  Consequentially:

  state.have_type = !!ent->fts_statp->st_mode
  
  ==> state.have_type = 0
  ==> state.type = 0
  ==> assert (state.type != 0) FAILs


Corinna

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

--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Eric Blake]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> > >Hmm.  After removing the /dev/fd directory that I had created years
> > >ago, find now just SEGVs.  And, it seems to be dying in find itself
> > >if the stack dump is any indication.
> > >
> > >Eric, is there any way that you could confirm or deny this?  I would
> > >rather not build a debugging version of find if I don't have to.

I still haven't had time to take a closer look into this.  But it's on my list.

> The assertion is basically
> 
>   if (ent->fts_info == FTS_NSOK || ent->fts_info == FTS_NS)
>     assert (state.type != 0);
> 
> state.type is set in the calling function find() like this:
> 
>   while ( (ent=fts_read(p)) != NULL )
>     {
>       state.have_type = !!ent->fts_statp->st_mode;
>       state.type = state.have_type ? ent->fts_statp->st_mode : 0;
>     }
> 
> which is a bug, AFAICS.  The reason is that per the fts_read man page
> the value of ent->fts_statp is undefined if ent->fts_info is FTS_NSOK
> or FTS_NS.  So the values of state.have_type and consequentially
> state.type are undefined as well and the above assertion makes no sense.

find uses gnulib's implementation of fts, not cygwin's.  Gnulib's variant has 
the added advantage of using openat() and friends, for linear instead of 
quadratic recursion speed on deep hierarchies (provided, of course, that you 
have an OS that supports linear speeds, and not all versions of Windows 
qualify), as well as thread-safety in multi-threaded apps (BSD and glibc fts 
are not thread-safe, since they can call chdir).  Therefore, this might not 
actually be a bug in find, because of the difference in fts implementations 
(the gnulib folks have been debating about renaming their implementation gfts, 
to document that it is a better interface than traditional fts).

I also know about a recent upstream patch that fixed the use of an 
uninitialized variable related to st_mode, that was not part of findutils 
4.5.3.  I'm not sure if it is related to this particular issue, but it is a 
possibility.

-- 
Eric Blake



--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Corinna Vinschen]

On Jan  8 16:36, Eric Blake wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > The assertion is basically
> > 
> >   if (ent->fts_info == FTS_NSOK || ent->fts_info == FTS_NS)
> >     assert (state.type != 0);
> > 
> > state.type is set in the calling function find() like this:
> > 
> >   while ( (ent=fts_read(p)) != NULL )
> >     {
> >       state.have_type = !!ent->fts_statp->st_mode;
> >       state.type = state.have_type ? ent->fts_statp->st_mode : 0;
> >     }
> > 
> > which is a bug, AFAICS.  The reason is that per the fts_read man page
> > the value of ent->fts_statp is undefined if ent->fts_info is FTS_NSOK
> > or FTS_NS.  So the values of state.have_type and consequentially
> > state.type are undefined as well and the above assertion makes no sense.
> 
> find uses gnulib's implementation of fts, not cygwin's.
> [...]
> I also know about a recent upstream patch that fixed the use of an 
> uninitialized variable related to st_mode, that was not part of findutils 
> 4.5.3.  I'm not sure if it is related to this particular issue, but it is a 
> possibility.

That's what happens in gnulib's fts in case of returning FTS_NS:

  memset(sbp, 0, sizeof(struct stat));
  return (FTS_NS);

So st_mode is 0 here, too and the same problem occurs.


Corinna

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

--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 1/9/2009 4:45 AM:
> That's what happens in gnulib's fts in case of returning FTS_NS:
> 
>   memset(sbp, 0, sizeof(struct stat));
>   return (FTS_NS);
> 
> So st_mode is 0 here, too and the same problem occurs.

Here's what I'm reporting upstream:

when d_type directory traversal is enabled, the following sequence is okay:

$ mkdir example
$ ln -s /nowhere example/n
$ find -L example
example
example/n

but the following asserts:

$ rm example/n
$ ln -s //nowhere example/n
$ find -L example
example
assertion "state.type != 0" failed: file
"/usr/src/findutils-4.5.3-1/src/findutils-4.5.3/find/ftsfind.c", line 475,
function: consider_visiting
Aborted (core dumped)

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpMa0ACgkQ84KuGfSFAYAffgCgy5y0VEA/ACr3v0AX9li0/iYy
Bg8AoIrgALf8b75OZdqDIDfcC2+H/PI/
=DvwO
-----END PGP SIGNATURE-----

--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 1/9/2009 4:45 AM:
>>> state.type is set in the calling function find() like this:
>>>
>>>   while ( (ent=fts_read(p)) != NULL )
>>>     {
>>>       state.have_type = !!ent->fts_statp->st_mode;
>>>       state.type = state.have_type ? ent->fts_statp->st_mode : 0;
>>>     }
>>>
>>> which is a bug, AFAICS.

The bug is not here, since gnulib's fts is smart enough to populate
ent->fts_statp->st_mode (but nothing else) using d_type information
learned during readdir when FTS_NOSTAT is requested, thus deferring (or
avoiding) the need for stat.  In other words, state.type can be valid even
when a FTS_NSOK or FTS_NS.

But the later assertion is a bug, since it is possible to have neither the
stat (since find used FTS_NOSTAT) nor a type (when d_type was DT_UNKNOWN),
in which case a stat must be performed.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpUBcACgkQ84KuGfSFAYCwvwCfZRvs0DRCoBL+YRsqgs5HbF6y
kXcAoJjbwRzxqCHcxHLady4XB/MNLUFX
=K7yf
-----END PGP SIGNATURE-----

--
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/

Re: find assert

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Christopher Faylor on 12/30/2008 12:06 PM:
> This is apparently caused by a symlink that looks like this:
> 
> lrwxrwxrwx  1 cgf None       6 Jul  9  2005 n -> //none
> 
> I don't remember creating that symlink.  Apparently I was checking on
> creating symlinks to nonexistent domains back in 2005.
> 
> I don't know if this is a find bug or a cygwin bug.  I could see it
> being either or both.

To some degree, it is a cygwin bug, when "n" points to "//nowhere".  If
stat("n",&st) were to fail with the standardized ENOENT, rather than the
cygwin-specific ENOSHARE, then fts_read would have set fts_info to
FTS_SLNONE (a dangling symlink) rather than FTS_NS (stat failed, possibly
from ELOOP).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklpWnQACgkQ84KuGfSFAYBS9wCgvEDxapIJn/OqXtwswhvl7qkT
HJUAn3EOtcp/+LBKLYyS188PyuthKjGB
=Dwt9
-----END PGP SIGNATURE-----

--
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/

Re: find assert

[Corinna Vinschen]

On Jan 10 19:33, Eric Blake wrote:
> According to Christopher Faylor on 12/30/2008 12:06 PM:
> > This is apparently caused by a symlink that looks like this:
> > 
> > lrwxrwxrwx  1 cgf None       6 Jul  9  2005 n -> //none
> > 
> > I don't remember creating that symlink.  Apparently I was checking on
> > creating symlinks to nonexistent domains back in 2005.
> > 
> > I don't know if this is a find bug or a cygwin bug.  I could see it
> > being either or both.
> 
> To some degree, it is a cygwin bug, when "n" points to "//nowhere".  If
> stat("n",&st) were to fail with the standardized ENOENT, rather than the
> cygwin-specific ENOSHARE, then fts_read would have set fts_info to
> FTS_SLNONE (a dangling symlink) rather than FTS_NS (stat failed, possibly
> from ELOOP).

Are you proposing that Cygwin should change setting errno from ENOSHARE
to ENOENT?  ENOSHARE is only set in one single instance and is only
explicitly requested in another.  AFAICS, dropping ENOSHARE entirely
would only simplify the code and should have no negative consequences
(knock on wood here).


Corinna

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

--
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/

Re: find assert

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Corinna Vinschen on 1/11/2009 2:16 AM:
>> To some degree, it is a cygwin bug, when "n" points to "//nowhere".  If
>> stat("n",&st) were to fail with the standardized ENOENT, rather than the
>> cygwin-specific ENOSHARE, then fts_read would have set fts_info to
>> FTS_SLNONE (a dangling symlink) rather than FTS_NS (stat failed, possibly
>> from ELOOP).
> 
> Are you proposing that Cygwin should change setting errno from ENOSHARE
> to ENOENT?  ENOSHARE is only set in one single instance and is only
> explicitly requested in another.  AFAICS, dropping ENOSHARE entirely
> would only simplify the code and should have no negative consequences
> (knock on wood here).

Changing from ENOSHARE to ENOENT would certainly be more POSIX-compliant -
the error is conveying the information that a path does not exist.  Also,
if you put some historical context on the problem, ENOSHARE predates the
implementation of the // namespace.  Back when //server did not represent
a valid path name, it made sense to have a different error for
//nosuch/share seeing as how //nosuch could never resolve on its own.  But
now that //nosuch can potentially resolve, it makes sense to treat it like
any other path name that can potentially resolve, by returning ENOENT.

However, I discovered that find still has a bug, whether or not we change
away from using ENOSHARE; the assert was also reproducible in this situation:

$ mkdir example
$ ln -s loop example/loop
$ find -L example

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklqBnMACgkQ84KuGfSFAYCztQCgo/d7I4lDUrppbl7AowdEJDV8
K14An2zZoXXEDAH9Q1xbof0AgqxLfK1t
=deOC
-----END PGP SIGNATURE-----

--
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/

Re: find assert

[Corinna Vinschen]

On Jan 11 07:47, Eric Blake wrote:
> According to Corinna Vinschen on 1/11/2009 2:16 AM:
> > Are you proposing that Cygwin should change setting errno from ENOSHARE
> > to ENOENT?  ENOSHARE is only set in one single instance and is only
> > explicitly requested in another.  AFAICS, dropping ENOSHARE entirely
> > would only simplify the code and should have no negative consequences
> > (knock on wood here).
> 
> Changing from ENOSHARE to ENOENT would certainly be more POSIX-compliant -
> the error is conveying the information that a path does not exist.  Also,
> if you put some historical context on the problem, ENOSHARE predates the
> implementation of the // namespace.  Back when //server did not represent
> a valid path name, it made sense to have a different error for
> //nosuch/share seeing as how //nosuch could never resolve on its own.  But
> now that //nosuch can potentially resolve, it makes sense to treat it like
> any other path name that can potentially resolve, by returning ENOENT.

That makes sense.  I changed ENOSHARE to ENOENT throughout.


Corinna

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

--
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/

Re: find assert (was Re: [1.7] System reboot (udfs.sys),...)

[Gregory Sharp]

[-- Attachment #1: Type: text/plain, Size: 4285 bytes --]

> assertion "state.type != 0" failed: file
"/usr/src/findutils-4.5.3-1/src/findutils-4.5.3/find/ftsfind.c",
line 475, function: consider_visiting
> 
> This is apparently caused by a symlink that looks like this:
> 
> lrwxrwxrwx  1 cgf None       6 Jul  9  2005 n -> //none

I confirm the assert in find.  Testing cygwin 1.7 on 
Windows Vista Business SP1 yields crash (not reboot) 
with identical assertion failure.

Fault trigger, however, might be different.  Your trigger 
was on invalid symlink.  My failure on Vista+UDFS occurs 
when find encounters a filename not consistent with current 
locale.  I can't find any pattern to the trigger for 
reboot on Win2k.

Details from tests on Vista are below (song #5 has an 
accent over the i).  Note also the output from "ls".
Why are permissions, owner, etc. messed up?

Cygcheck for Vista PC attached.

Thanks for your help.  Please let me know if there is 
anything else I can test.

Greg

-----------------------------------------------------

gcs6@slumber /cygdrive/e/Enya
$ echo $CYGWIN

gcs6@slumber /cygdrive/e/Enya
$ echo $LANG

gcs6@slumber /cygdrive/e/Enya
$ echo $LC_CTYPE

gcs6@slumber /cygdrive/e/Enya
$ find . -type f -exec cksum {} \;
345961327 13604075 ./A Day Without Rain/01 - Enya - A Day
Without Rain.flac
3680852238 24151922 ./A Day Without Rain/02 - Enya - Wild
Child.flac
3662859760 23902845 ./A Day Without Rain/03 - Enya - Only
Time.flac
1323646772 14051921 ./A Day Without Rain/04 - Enya - Tempus
Vernum.flac
cksum: ./A Day Without Rain/05 - Enya - Deora Ar Mo Chroi.flac:
No such file or
directory
2901799000 25825773 ./A Day Without Rain/06 - Enya - Flora's
Secret.flac
335980607 12891442 ./A Day Without Rain/07 - Enya - Fallen
Embers.flac
1477256642 8797182 ./A Day Without Rain/08 - Enya - Silver
Inches.flac
4027000500 18176956 ./A Day Without Rain/09 - Enya -
Pilgrim.flac
1861032574 24277084 ./A Day Without Rain/10 - Enya - One by
One.flac
40677686 22696897 ./A Day Without Rain/11 - Enya - Lazy
Days.flac

gcs6@slumber /cygdrive/e/Enya
$ find -L . -type f -exec cksum {} \;
345961327 13604075 ./A Day Without Rain/01 - Enya - A Day
Without Rain.flac
3680852238 24151922 ./A Day Without Rain/02 - Enya - Wild
Child.flac
3662859760 23902845 ./A Day Without Rain/03 - Enya - Only
Time.flac
1323646772 14051921 ./A Day Without Rain/04 - Enya - Tempus
Vernum.flac
assertion "state.type != 0" failed: file
"/usr/src/findutils-4.5.3-1/src/finduti
ls-4.5.3/find/ftsfind.c", line 475, function: consider_visiting
Stack trace:
Frame     Function  Args
0022C8D8  76EEC1B2  (00000218, 0000EA60, 000000A4, 0022C9CC)
0022C9E8  610B5E03  (00000000, 76EEC274, 775A7F54, 00000000)
0022CAC8  610B29A7  (00000000, 00000000, 00000000, 00000000)
0022CB18  610B2DBB  (00000A30, 0022CB40, 0022CB54, 0022CB54)
0022CBD8  610B2EE1  (00000A30, 00000006, 0022CC08, 610B2F85)
0022CBE8  610B2F1C  (00000006, 0022CE88, 0022CC08, 27790D43)
0022CC08  610B2F85  (6114C054, 0042B2AF, 0042B04C, 000001DB)
0022CC38  6100109B  (0042B04C, 000001DB, 0042B3B2, 0042B2AF)
0022CD08  610B01E8  (61282C0C, 00000001, 00000002, 00000009)
0022CD48  00401E4A  (00000009, 0000007F, 0022CD88, 61006EEA)
0022CD88  61006EEA  (00000000, 0022CDC0, 610067E0, 7FFDA000)
End of stack trace
Aborted (core dumped)

gcs6@slumber /cygdrive/e/Enya
$ ls -l A\ Day\ Without\ Rain/
ls: cannot access A Day Without Rain/05 - Enya - Deora Ar Mo
Chroi.flac: No such file or directory
total 183972
-r--r--r-- 1 gcs6 None 13604075 Dec 26 19:30 01 - Enya - A Day
Without Rain.flac
-r--r--r-- 1 gcs6 None 24151922 Dec 26 19:30 02 - Enya - Wild
Child.flac
-r--r--r-- 1 gcs6 None 23902845 Dec 26 19:30 03 - Enya - Only
Time.flac
-r--r--r-- 1 gcs6 None 14051921 Dec 26 19:30 04 - Enya - Tempus
Vernum.flac
-????????? ? ?    ?           ?            ? 05 - Enya - Deora
Ar Mo Chroi.flac
-r--r--r-- 1 gcs6 None 25825773 Dec 26 19:30 06 - Enya - Flora's
Secret.flac
-r--r--r-- 1 gcs6 None 12891442 Dec 26 19:30 07 - Enya - Fallen
Embers.flac
-r--r--r-- 1 gcs6 None  8797182 Dec 26 19:30 08 - Enya - Silver
Inches.flac
-r--r--r-- 1 gcs6 None 18176956 Dec 26 19:30 09 - Enya -
Pilgrim.flac
-r--r--r-- 1 gcs6 None 24277084 Dec 26 19:30 10 - Enya - One by
One.flac
-r--r--r-- 1 gcs6 None 22696897 Dec 26 19:30 11 - Enya - Lazy
Days.flac



Greg Sharp
gregsharp@geocities.com


      

[-- Attachment #2: 3924260979-cygcheck.out --]
[-- Type: application/octet-stream, Size: 14969 bytes --]


Cygwin Configuration Diagnostics
Current System Time: Wed Dec 31 16:19:25 2008

Windows Vista Business Edition Ver 6.0 Build 6001 Service Pack 1

Path:	C:\cygwin-1.7\usr\local\bin
	C:\cygwin-1.7\bin
	C:\cygwin-1.7\bin
	C:\cygwin-1.7\usr\X11R6\bin
	C:\Program Files\MiKTeX 2.7\miktex\bin
	C:\Program Files\Microsoft DirectX SDK (August 2007)\Utilities\Bin\x86
	C:\Windows\system32
	C:\Windows
	C:\Windows\System32\Wbem
	C:\Program Files\Common Files\GTK\2.0\bin
	C:\Program Files\Common Files\Roxio Shared\DLLShared\
	C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared\
	C:\Program Files\MathWorks\MATLAB Component Runtime\v72\runtime\win32
	C:\Windows\System32\WindowsPowerShell\v1.0\
	C:\CUDA\bin
	C:\Program Files\NVIDIA Corporation\Cg\bin
	C:\Program Files\Softex\OmniPass
	C:\bin

Output from c:\cygwin-1.7\bin\id.exe (nontsec)
UID: 1001(gcs6) GID: 513(None)
545(Users)      513(None)

Output from c:\cygwin-1.7\bin\id.exe (ntsec)
UID: 1001(gcs6) GID: 513(None)
545(Users)      513(None)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'gcs6'
PWD = '/cygdrive/c/gcs6'
HOME = '/cygdrive/c/gcs6'
MAKE_MODE = 'unix'

HOMEPATH = '\Users\gcs6'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Users\gcs6\AppData\Roaming'
CUDA_INC_PATH = 'C:\CUDA\include'
HOSTNAME = 'slumber'
DXSDK_DIR = 'C:\Program Files\Microsoft DirectX SDK (August 2007)\'
TERM = 'cygwin'
STREAMRIPPER_DEBUG = 'C:\gcs6\projects\sripper_1x\gcs.txt'
RoxioCentral = 'C:\Program Files\Common Files\Roxio Shared\9.0\Roxio Central33\'
PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
CG_BIN_PATH = 'C:\Program Files\NVIDIA Corporation\Cg\bin'
WINDIR = 'C:\Windows'
VS80COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\'
CG_INC_PATH = 'C:\Program Files\NVIDIA Corporation\Cg\include'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/e'
USERDOMAIN = 'slumber'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
!:: = '::\'
TEMP = '/cygdrive/c/Users/gcs6/AppData/Local/Temp'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
configsetroot = 'C:\Windows\ConfigSetRoot'
USERNAME = 'gcs6'
PROCESSOR_LEVEL = '6'
CUDA_BIN_PATH = 'C:\CUDA\bin'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
CUDA_LIB_PATH = 'C:\CUDA\lib'
USERPROFILE = 'C:\Users\gcs6'
CG_LIB_PATH = 'C:\Program Files\NVIDIA Corporation\Cg\lib'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\SLUMBER'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\gcs6\AppData\Local'
!C: = 'c:\cygwin-1.7\bin'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
PROMPT = '$P$G'
HOMEDIR = '\gcs6'
COMSPEC = 'C:\Windows\system32\cmd.exe'
TMP = '/cygdrive/c/Users/gcs6/AppData/Local/Temp'
SYSTEMROOT = 'C:\Windows'
PRINTER = 'Fax'
PROCESSOR_REVISION = '0f06'
NVSDKCUDA_ROOT = 'C:\Program Files\NVIDIA Corporation\NVIDIA CUDA SDK'
CVS_RSH = '/bin/ssh'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files'
NUMBER_OF_PROCESSORS = '2'
SESSIONNAME = 'Console'
COMPUTERNAME = 'SLUMBER'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x00000022
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'c:\cygwin'
  flags = 0x0000000a
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'c:\cygwin/bin'
  flags = 0x0000000a
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'c:\cygwin/lib'
  flags = 0x0000000a
HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
  (default) = '/cygdrive'
  cygdrive flags = 0x00000022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = 'c:\cygwin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = 'c:\cygwin/bin'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = 'c:\cygwin/lib'
  flags = 0x0000000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options

c:  hd  NTFS     92821Mb  86% CP CS UN PA FC     
d:  hd  NTFS      1035Mb   4% CP CS UN PA FC     
e:  cd  UDF       4462Mb 100% CP CS UN           081229_0942

c:/cygwin-1.7      /          system  binmode
c:\cygwin-1.7\bin  /usr/bin   system  binmode
c:\cygwin-1.7\lib  /usr/lib   system  binmode
.                  /cygdrive  user    binmode,cygdrive

Found: C:\cygwin-1.7\bin\awk.exe
Found: C:\cygwin-1.7\bin\awk.exe
 -> c:\cygwin-1.7\bin\gawk.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\bash.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cat.exe
Found: C:\cygwin-1.7\bin\cp.exe
Found: C:\cygwin-1.7\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\cygwin-1.7\bin\find.exe
Found: C:\Windows\system32\find.exe
Warning: C:\cygwin-1.7\bin\find.exe hides C:\Windows\system32\find.exe
Not Found: gcc
Not Found: gdb
Found: C:\cygwin-1.7\bin\grep.exe
Found: C:\cygwin-1.7\bin\grep.exe
Found: C:\cygwin-1.7\bin\kill.exe
Found: C:\cygwin-1.7\bin\kill.exe
Not Found: ld
Found: C:\cygwin-1.7\bin\ls.exe
Found: C:\cygwin-1.7\bin\ls.exe
Not Found: make
Found: C:\cygwin-1.7\bin\mv.exe
Found: C:\cygwin-1.7\bin\mv.exe
Not Found: patch
Not Found: perl
Found: C:\cygwin-1.7\bin\rm.exe
Found: C:\cygwin-1.7\bin\rm.exe
Found: C:\cygwin-1.7\bin\sed.exe
Found: C:\cygwin-1.7\bin\sed.exe
Not Found: ssh
Found: C:\cygwin-1.7\bin\sh.exe
Found: C:\cygwin-1.7\bin\sh.exe
Found: C:\cygwin-1.7\bin\tar.exe
Found: C:\cygwin-1.7\bin\tar.exe
Found: C:\cygwin-1.7\bin\test.exe
Found: C:\cygwin-1.7\bin\test.exe
Not Found: vi
Not Found: vim

   61k 2008/04/01 C:\cygwin-1.7\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz2-1.dll" v0.0 ts=2008/3/31 23:37
   40k 2006/11/15 C:\cygwin-1.7\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygform-8.dll" v0.0 ts=2006/11/15 2:06
  219k 2008/10/04 C:\cygwin-1.7\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggmp-3.dll" v0.0 ts=2008/10/4 19:48
  288k 2008/10/04 C:\cygwin-1.7\bin\cyggmpxx-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggmpxx-3.dll" v0.0 ts=2008/10/4 19:48
   24k 2008/11/29 C:\cygwin-1.7\bin\cyghistory6.dll - os=4.0 img=1.0 sys=4.0
                  "cyghistory6.dll" v0.0 ts=2008/11/29 9:30
  271k 2007/08/24 C:\cygwin-1.7\bin\cygicons-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygicons-0.dll" v0.0 ts=2007/8/24 3:24
  978k 2008/11/10 C:\cygwin-1.7\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygiconv-2.dll" v0.0 ts=2008/11/9 19:35
   31k 2005/11/20 C:\cygwin-1.7\bin\cygintl-3.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-3.dll" v0.0 ts=2005/11/19 21:04
   31k 2008/12/29 C:\cygwin-1.7\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-8.dll" v0.0 ts=2008/12/29 15:45
    5k 2008/12/23 C:\cygwin-1.7\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
                  "cyglsa.dll" v0.0 ts=2008/12/23 16:07
    9k 2008/12/23 C:\cygwin-1.7\bin\cyglsa64.dll - os=4.0 img=0.0 sys=5.2
   21k 2006/11/15 C:\cygwin-1.7\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu-8.dll" v0.0 ts=2006/11/15 2:05
  121k 2008/10/04 C:\cygwin-1.7\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cygmp-3.dll" v0.0 ts=2008/10/4 19:48
   67k 2006/11/15 C:\cygwin-1.7\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++-8.dll" v0.0 ts=2006/11/15 2:13
  237k 2006/11/15 C:\cygwin-1.7\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses-8.dll" v0.0 ts=2006/11/15 2:02
   12k 2006/11/15 C:\cygwin-1.7\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel-8.dll" v0.0 ts=2006/11/15 2:04
  181k 2008/09/07 C:\cygwin-1.7\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcre-0.dll" v0.0 ts=2008/9/6 23:36
  302k 2008/09/07 C:\cygwin-1.7\bin\cygpcrecpp-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcrecpp-0.dll" v0.0 ts=2008/9/6 23:36
    7k 2008/09/07 C:\cygwin-1.7\bin\cygpcreposix-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcreposix-0.dll" v0.0 ts=2008/9/6 23:36
   22k 2002/06/09 C:\cygwin-1.7\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpopt-0.dll" v0.0 ts=2002/6/9 1:45
  155k 2008/11/29 C:\cygwin-1.7\bin\cygreadline6.dll - os=4.0 img=1.0 sys=4.0
                  "cygreadline6.dll" v0.0 ts=2008/11/29 9:30
 2364k 2008/12/23 C:\cygwin-1.7\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2008/12/23 16:07
    Cygwin DLL version info:
        DLL version: 1.7.0
        DLL epoch: 19
        DLL old termios: 5
        DLL malloc env: 28
        API major: 0
        API minor: 190
        Shared data: 5
        DLL identifier: cygwin1
        Mount registry: 3
        Cygwin registry name: Cygwin
        Program options name: Program Options
        Cygdrive default prefix: 
        Build date: Tue Dec 23 16:07:34 EST 2008
        Shared id: cygwin1S5

   61k 2008/04/01 C:\cygwin-1.7\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz2-1.dll" v0.0 ts=2008/3/31 23:37
   40k 2006/11/15 C:\cygwin-1.7\bin\cygform-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygform-8.dll" v0.0 ts=2006/11/15 2:06
  219k 2008/10/04 C:\cygwin-1.7\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggmp-3.dll" v0.0 ts=2008/10/4 19:48
  288k 2008/10/04 C:\cygwin-1.7\bin\cyggmpxx-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggmpxx-3.dll" v0.0 ts=2008/10/4 19:48
   24k 2008/11/29 C:\cygwin-1.7\bin\cyghistory6.dll - os=4.0 img=1.0 sys=4.0
                  "cyghistory6.dll" v0.0 ts=2008/11/29 9:30
  271k 2007/08/24 C:\cygwin-1.7\bin\cygicons-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygicons-0.dll" v0.0 ts=2007/8/24 3:24
  978k 2008/11/10 C:\cygwin-1.7\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygiconv-2.dll" v0.0 ts=2008/11/9 19:35
   31k 2005/11/20 C:\cygwin-1.7\bin\cygintl-3.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-3.dll" v0.0 ts=2005/11/19 21:04
   31k 2008/12/29 C:\cygwin-1.7\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-8.dll" v0.0 ts=2008/12/29 15:45
    5k 2008/12/23 C:\cygwin-1.7\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
                  "cyglsa.dll" v0.0 ts=2008/12/23 16:07
    9k 2008/12/23 C:\cygwin-1.7\bin\cyglsa64.dll - os=4.0 img=0.0 sys=5.2
   21k 2006/11/15 C:\cygwin-1.7\bin\cygmenu-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu-8.dll" v0.0 ts=2006/11/15 2:05
  121k 2008/10/04 C:\cygwin-1.7\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cygmp-3.dll" v0.0 ts=2008/10/4 19:48
   67k 2006/11/15 C:\cygwin-1.7\bin\cygncurses++-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++-8.dll" v0.0 ts=2006/11/15 2:13
  237k 2006/11/15 C:\cygwin-1.7\bin\cygncurses-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses-8.dll" v0.0 ts=2006/11/15 2:02
   12k 2006/11/15 C:\cygwin-1.7\bin\cygpanel-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel-8.dll" v0.0 ts=2006/11/15 2:04
  181k 2008/09/07 C:\cygwin-1.7\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcre-0.dll" v0.0 ts=2008/9/6 23:36
  302k 2008/09/07 C:\cygwin-1.7\bin\cygpcrecpp-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcrecpp-0.dll" v0.0 ts=2008/9/6 23:36
    7k 2008/09/07 C:\cygwin-1.7\bin\cygpcreposix-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcreposix-0.dll" v0.0 ts=2008/9/6 23:36
   22k 2002/06/09 C:\cygwin-1.7\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpopt-0.dll" v0.0 ts=2002/6/9 1:45
  155k 2008/11/29 C:\cygwin-1.7\bin\cygreadline6.dll - os=4.0 img=1.0 sys=4.0
                  "cygreadline6.dll" v0.0 ts=2008/11/29 9:30
 2364k 2008/12/23 C:\cygwin-1.7\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2008/12/23 16:07
    Cygwin DLL version info:
        DLL version: 1.7.0
        DLL epoch: 19
        DLL old termios: 5
        DLL malloc env: 28
        API major: 0
        API minor: 190
        Shared data: 5
        DLL identifier: cygwin1
        Mount registry: 3
        Cygwin registry name: Cygwin
        Program options name: Program Options
        Cygdrive default prefix: 
        Build date: Tue Dec 23 16:07:34 EST 2008
        Shared id: cygwin1S5


Can't find the cygrunsrv utility, skipping services check.


Cygwin Package Information
Last downloaded files to: C:\Users\gcs6\tmp\cygwin-1.7
Last downloaded files from: http://cygwin.osuosl.org/

Package              Version
_update-info-dir     00792-1
alternatives         1.3.30c-2
ash                  20040127-4
base-cygwin          1.1-3
base-files           3.7-1
base-passwd          2.2-1
bash                 3.2.48-21
bzip2                1.0.5-2
coreutils            7.0-2
cygutils             1.3.2-1
cygwin               1.7.0-37
cygwin-doc           1.5-1
editrights           1.01-2
findutils            4.5.3-1
gawk                 3.1.6-1
grep                 2.5.3-1
groff                1.19.2-2
gzip                 1.3.12-2
ipc-utils            1.0-1
less                 382-1
libbz2_1             1.0.5-2
libgmp3              4.2.4-1
libiconv2            1.12-1
libintl3             0.14.5-1
libintl8             0.17-2
libncurses8          5.5-3
libpcre0             7.8-1
libpopt0             1.6.4-4
libreadline6         5.2.13-11
login                1.9-8
man                  1.6e-1
rebase               2.4.4-1
run                  1.1.10-1
sed                  4.1.5-2
tar                  1.21-2
termcap              20050421-1
terminfo             5.5_20061104-1
texinfo              4.8a-1
tzcode               2008h-1
which                2.20-2
Use -h to see help about each section

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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/