Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Date: Wed, 24 Jul 2002 01:49:55 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin-developers AT cygwin DOT com
Subject: Re: path_conv::check() gets confused by recently removed files
Message-ID: <20020724054954.GA26631@redhat.com>
Reply-To: cygwin-developers AT cygwin DOT com
Mail-Followup-To: cygwin-developers AT cygwin DOT com
References: <20020722164156 DOT GI1680 AT tishler DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20020722164156.GI1680@tishler.net>
User-Agent: Mutt/1.3.23.1i

On Mon, Jul 22, 2002 at 12:41:57PM -0400, Jason Tishler wrote:
>I guess that I found the complement of the following:
>
>    http://cygwin.com/ml/cygwin-developers/2002-05/msg00008.html
>
>while tracking down some regressions with Cygwin Python CVS. :,)

Actually, AFAICT, this is completely unrelated.

>The attached test program, j7.cc, demonstrates the problem:
>
>    $ >file
>    $ j7 file
>    dir
>
>The root cause of the problem is that symlink_info::check() ignores the
>ERROR_ACCESS_DENIED case in the following:
>
>    fileattr = GetFileAttributes (suffix.path);
>    if (fileattr == INVALID_FILE_ATTRIBUTES)
>    {
>      /* The GetFileAttributes call can fail for reasons that don't
>         matter, so we just return 0.  For example, getting the
>         attributes of \\HOST will typically fail.  */
>      debug_printf ("GetFileAttributes (%s) failed", suffix.path);
>      error = geterrno_from_win_error (GetLastError (), EACCES);
>      continue;
>    }

Actually, AFAICT, it is not being ignored.

>The above causes path_conv::check() to the lop off the tail component of
>the recently deleted file so that path_conv::fileattr incorrectly
>indicates a directory instead of a file.  This in turn, causes fstat()
>to incorrectly indicate that the file descriptor is a directory instead
>of a file.

Did you run this in a debugger?  I don't see this.  It would be a pretty
serious bug if that was the case.  It would mean that every stat of
a nonexistent file would return EISDIR since it would always be finding
the parent directory.

Your test case isn't demonstrating a problem with a recently removed
file.  It is showing a problem with a file that has been removed while
there is still an open fd.

The real problem was that, after calling path_conv::check, some later fstat
code was using the fileattr field in path_conv without first checking if
the file existed.  So, it was checking bit fields in a value that was
essentially set to -1.

The solution is to always use the methods that I introduced for
manipulating the fileattr.  I did that and also made fileattr private so
that it will be obvious that this field should not be used in the
future.

This should be fixed in the next snapshot.  Thanks for the bug report.

cgf