Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Date: Thu, 4 Oct 2001 21:00:34 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: 1.3.3: stat() broken on /dev/null/some/file
Message-ID: <20011004210034.A1118@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <134653617 DOT 1002241386599 DOT JavaMail DOT root AT boots>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <134653617.1002241386599.JavaMail.root@boots>
User-Agent: Mutt/1.3.21i

On Thu, Oct 04, 2001 at 08:15:12PM -0000, kefg5vm40bt001 AT sneakemail DOT com wrote:
>The stat() system call seems to return successfully for paths
>deeper than /dev/null. Is that the expected behaviour? This is
>due to the recursive algorithm in path.cc that analyses every
>path elements in reverse order for possible symbolic links. Other
>unices seem to behave differently. This causes for example the
>libtool(1.4.2) testsuite to fail on cygwin for the test cases
>that use CONFIG_SITE=/dev/null/config/site to set $CONFIG_SITE
>to a non-existing file.
>
>access.exe relies on the stat() system call (when using the -r flag),
>so the test case for this behaviour is fairly straightforward:
>
>$ (access -r /dev/null/some/file && echo FAIL) || echo PASS
>FAIL
>
>I would greatly appreciate any insight, as i got lost in the inner
>workings of path.cc when trying to fix this problem. I collected
>some information below.

While, I greatly appreciate the fact that you're trying to track this
down, the information you provided was just 250 lines of strace.  Anyone
could do this.  Just do a "strace -ostrace.out ls -l /dev/tty/somefile"
(since it is actually a problem with any device).  There is no reason to
send strace output to thousands of people on the mailing list unless you
actually added some annotation with your findings about what was going
on.

The way to figure out what is going on is to use gdb to step into
path_conv::check and see why the code isn't stopping and returning an
error when it hits a device.  The place to check would be where
path_conv::check determines that it has found a device.  If there is a
trailing component after the device spec, then there is an obvious
error and an appropriate error should be returned.

If you don't know how to use gdb to debug cygwin, then check out Egor
Duda's "how-to-debug-cygwin.txt" in the winsup/cygwin directory.

Anyway, this is all for future reference.  I've fixed the problem.  The
patch below (which I've just checked in) seems to do the right thing.

cgf

>Stephane
>------------------------------------------------------------------
>$ uname -a
>CYGWIN_NT-4.0 CYCLOP 1.3.3(0.46/3/2) 2001-09-12 23:54 i686 unknown
>
>$ strace access -r /dev/null/some/file
>**********************************************
>Program name: E:\cygwin\bin\access.exe (432)
>App version:  1001.8, api: 0.34
>DLL version:  1003.3, api: 0.46
>DLL build:    2001-09-12 23:54
>OS version:   Windows NT-4.0
>Date/Time:    2001-10-05 01:04:00
>**********************************************
>[snip]

Index: path.cc
===================================================================
RCS file: /cvs/uberbaum/winsup/cygwin/path.cc,v
retrieving revision 1.166
diff -p -r1.166 path.cc
*** path.cc	2001/10/05 00:17:57	1.166
--- path.cc	2001/10/05 00:47:28
*************** path_conv::check (const char *src, unsig
*** 474,479 ****
--- 474,484 ----
  	  /* devn should not be a device.  If it is, then stop parsing now. */
  	  if (devn != FH_BAD)
  	    {
+ 	      if (component)
+ 		{
+ 		  error = ENOTDIR;
+ 		  return;
+ 		}
  	      fileattr = 0;
  	      goto out;		/* Found a device.  Stop parsing. */
  	    }

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/