> Here's a question: Did you switch on case sensitivity as per
> http://cygwin.com/1.7/cygwin-ug-net.html#pathnames-casesensitive ?
> If yes, change your cygdrive prefix in /etc/fstab to contain the
> additional option "posix=0, as per
> http://cygwin.com/1.7/cygwin-ug-net.html#mount-table and try
On Jan 28 15:46, Gregory Sharp wrote:
> Hi,
>
> > That makes sense. I changed ENOSHARE to ENOENT throughout.
>
> I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still
> reboots my windows 2000 computer.
Here's a question: Did you switch on case sensitivity as per
http://cygwin.com/1.7/cy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gregory Sharp on 1/28/2009 4:46 PM:
> Hi,
>
>> That makes sense. I changed ENOSHARE to ENOENT throughout.
>
> I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still
> reboots my windows 2000 computer. Was the above change
> suppo
Hi,
> That makes sense. I changed ENOSHARE to ENOENT throughout.
I upgraded my cygwin 1.7 today, but cygwin+find+UDFS still
reboots my windows 2000 computer. Was the above change
supposed to have solved the problem?
Thank you,
Greg
Greg Sharp
gregsh...@geocities.com
--
Unsubscrib
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 ENOSHAR
-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
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
-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
-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
15 matches
Mail list logo
