-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 = sta
-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 w
On Jan 8 16:36, Eric Blake wrote:
> Corinna Vinschen 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 ( (e
Corinna Vinschen 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?
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.
> >
> 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 f
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 den
7 matches
Mail list logo