This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: path_conv::check() gets confused by recently removed files


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]