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/